Are there any plans to add nullable sugar to java.util.Optional? I’m not saying that generated APIs should use them where previously there were nullable return types, but being able to treat Optional values as nullable from other APIs or, when implementing interfaces from those APIs, return a nullable value where an Optional is expected, would be really really really nice.

I don’t think kotlin would benefit from any syntactic sugar for optionals. It would just lead to people using them even though they are inferior to nullables in any regard.
If you have to interface with java code using optionals often you could just create 2 little utility functions

I have those already, but it would be nice to not need to use them at all. And I don’t think it would lead to people using them over nullable types - I’m talking just about compatibility. The same way Kotlin has SAM conversions, but not if the interface was defined in Kotlin.

The special language feature for that is absolutely unnecessary. If you are using kotlin, than optional are needless and you are better to remove them from code and replace by nullables. If you are interacting with java code, then functions (I use properties) like the ones shown by @Wasabi375 are quite sufficient.

Because maximum that could be done is the standard library support for conversion methods or properties. No language changes will be ever done for the feature that requires two additional lines of code for the whole program.

However I am not sure how this would work with functions returning a nullable value, because you can’t overload just based on the return type. But I guess there might be some tricks that can be done by renaming the generated function visible to the jvm.
That way at least it would be possible to solve the problem of implementing interfaces using Optionals.