Would it be helpful if the Kotlin language would a...

# announcements

[Erik]

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.

[Erik]

This is just a random thought I just had

[Erik]

Possibly there are issues with this

[Erik]

Or possibly this has already been taken into consideration

[CLOVIS]

Oh, that sounds interesting, I think we quite often write

val foo: Something? = something()

[Erik]

Yes, where something() returns Something normally

[CLOVIS]

I like the syntax for literals (1?, "something"?), but for functions results it might look a little bit too much like ?.

[Erik]

I know, that's the clash. But it does convey the same meaning, type-wise

[Erik]

You could then write `something()??????.something`Else`()`

[Erik]

But that makes no sense

[Erik]

But the linter would warn you then

[Hanno]

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 :)

[CLOVIS]

@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.

[CLOVIS]

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

[Hanno]

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 :)

[Youssef Shoaib [MOD]]

You could probably make an extension property on every non nullable that looks like this:

val <T: Any> T.nullable: T? get() = this