https://kotlinlang.org logo
#announcements
Title
# announcements
e

Erik

08/26/2020, 8:17 AM
Would it be helpful if the Kotlin language would allow
?
as an expression suffix to coerce the expression to be of nullable type? Examples:
var x = 1?
-> inferred type =
Int?
, so no need to type
var x: Int? = 1
. Later you can always set
x = null
.
someQuery()?
-> inferred type = nullable return type of
someQuery()
. If that function already returns a nullable type, then a linter warning should be shown that the
?
suffix is redundant.
This is just a random thought I just had
Possibly there are issues with this
Or possibly this has already been taken into consideration
c

CLOVIS

08/26/2020, 12:50 PM
Oh, that sounds interesting, I think we quite often write
val foo: Something? = something()
e

Erik

08/26/2020, 12:54 PM
Yes, where
something()
returns
Something
normally
c

CLOVIS

08/26/2020, 2:03 PM
I like the syntax for literals (
1?
,
"something"?
), but for functions results it might look a little bit too much like
?.
e

Erik

08/26/2020, 2:10 PM
I know, that's the clash. But it does convey the same meaning, type-wise
You could then write `something()??????.something`Else`()`
But that makes no sense
But the linter would warn you then
h

Hanno

08/26/2020, 2:36 PM
I would ask how often a nullable var is a good idea and whether the language should really care about Making such a case more convenient, while i also don't see much benefit compared to specifying the nullable type :)
c

CLOVIS

08/26/2020, 3:08 PM
@Hanno I find it a bit frustrating that the language has type inference and can understand what type
1
is, but if you want
Int?
you have to declare the type. For such examples, it's kind of like writing
1f
instead of
1.toFloat()
, it carries the same meaning but is much smaller.
But yeah, I agree it's not code I wrote very often either, but I also don't think it adds any complexity or difficulty to the language, since it's a very straightforward feature, so I don't see a downside
h

Hanno

08/26/2020, 3:17 PM
Uhh, i don't agree at all here. 1. The type inference can understand both cases, it's just that it inferes from what you feed it. Changing the initializer code to make the inference do what you are want is imo worse than just declaring clearly what you want the type to be. 2. 1f and 1.toFloat() is Not the same at all. One is const literal and the other one is a function call that could even throw, be overriden by a local definition or whatever. It may end up as the same value in your example (and i am not even 100% sure with so much complexity even simple things can hide), but that's just in your example. 3. Complexity and diffuculty is added to the language because a new feature and syntax alone is added. This is a downside as long as the feature doesn't add a lot of benefit, which i can't see here :)
👆 1
💯 1
y

Youssef Shoaib [MOD]

08/28/2020, 8:51 AM
You could probably make an extension property on every non nullable that looks like this:
Copy code
val <T: Any> T.nullable: T? get() = this