Channels
#language-proposals
- l
loganj
05/27/2016, 1:04 PMdone and done - d
dmitry.petrov
05/27/2016, 1:07 PMthanks 🙂 - k
kittinunf
05/27/2016, 1:08 PMThis would help Android folks quite a lot. - d
dmitry.petrov
05/27/2016, 1:08 PMNB: in your example,
can't "refine" its arguments (otherwise it will not override the original method). Covariant return types (that is, "refined" return type of the getter in your example) are ok, and are used rather frequently.setText - j
jkbbwr
05/27/2016, 1:20 PMCould kotlin autowrap Optional<T> to T? - j
jkbbwr
05/27/2016, 1:20 PMBecause they are semantically the same - l
loganj
05/27/2016, 1:23 PM@dmitry.petrov: of course. I pointed it out b/c on EditText, there ends up being no property setter for what really is a mutable property. I just thought it was an interesting wrinkle in their API. - e
evanchooly
05/27/2016, 1:23 PMthat’d be akin to type promotion which kotlin avoids so far. - e
evanchooly
05/27/2016, 1:24 PMt: T? = optional.get() - d
dmitry.petrov
05/27/2016, 1:26 PMoptional.orElse(null) - e
evanchooly
05/27/2016, 1:27 PMthat. 🙂 - d
dmitry.petrov
05/27/2016, 1:27 PMThere are some issues with such promotion: consider, for example, an interface with a method
.foo(Optional<T> x) - d
dmitry.petrov
05/27/2016, 1:28 PMwe could generate a bridge here, though - d
dmitry.petrov
05/27/2016, 1:29 PMSuch promotion should also handle quirky cases like
somehowOptional<Optional< ... T>..> - e
evanchooly
05/27/2016, 1:30 PMquirky cases like that are best handle by a punch to the esophagus👍 1 - k
kirillrakhman
05/27/2016, 1:45 PM
will throwoptional.get() - k
kevinmost
05/27/2016, 1:45 PMThat's why you use
though, right?.orElse(null) - k
kirillrakhman
05/27/2016, 1:46 PMyes - k
kirillrakhman
05/27/2016, 1:46 PMone of the reasons, many people don't like - k
kirillrakhman
05/27/2016, 1:46 PMIDEA even has an inspection for it - k
kirillrakhman
05/27/2016, 1:46 PMhow would you even express
with Kotlin?Optional<Optional<T>> - k
kirillrakhman
05/27/2016, 1:47 PMprobably
right?Optional<T?> - k
kirillrakhman
05/27/2016, 1:47 PMbut that doesn't make any sense - k
kirillrakhman
05/27/2016, 1:47 PMor maybeOptional<T>? - k
kevinmost
05/27/2016, 1:47 PMyou could always make yourself an extension function I guess
And then the nested Optionals could be used likeinline fun <T> Optional<T>.unwrap() = orElse(null)
. Kind of gross, but I think any way of working with a nested Optional would be grossoptional.unwrap()?.unwrap() - k
kirillrakhman
05/27/2016, 1:47 PMwhich is considered a bug by the JDK designers - k
kirillrakhman
05/27/2016, 1:48 PMthat's a sensible approach - k
kevinmost
05/27/2016, 1:48 PMCould even do
if you wanted to be able to call it on potentially-null `Optional`s tooinline fun <T> Optional<T>?.unwrap() = this?.orElse(null) - k
kirillrakhman
05/27/2016, 1:48 PMugh - k
kirillrakhman
05/27/2016, 1:49 PMI suggest not to have
anywhere, everOptional<T>?