don't people find it confusing that `Any?.toString()` returns "null" rather than actual null?

# announcements

[Dias]

don't people find it confusing that Any?.toString() returns "null" rather than actual null?

[Ruckus]

Of course not. fun Any?.toString(): String clearly returns String, not String?.

[Dias]

it's only clear if you look at the definition of Any?.toString()

[ghedeon]

It is confusing. It's one of those behaviours that you have to remember. Which usually means that you learn it by surprise. I had to look it up in the source code, first time I saw it.

[karelpeeters]

That's true, but you only need to look it up once simple smile

[ghedeon]

Personally, I was expecting "", but I guess it's made like this in order to mark it as a special case, idk.

[karelpeeters]

Then tostring for data classes would suck, Point(x=5, y=)

[Ruckus]

I disagree that it's "one of those behaviors you have to remember". If we're talking about Any?.toString(), we're talking about the definition. If we're talking about usage, it's fairly clear if I say value.toString() vs value?.toString(). If you understand nullability and safe execution in Kotlin, it seems perfectly clear.

[ghedeon]

Nullability is unrelated in my answer, mostly focused on the returned value. Seeing "null" string as item somewhere in the final collection or even as a button label on the screen was surprising because it's not a specified constant in java. Could be as well any kind of "special" string, deliberately chosen by JB. I'm not saying it's wrong, I'm saying that a lot of people will fail to guess what null.toString() is going to return from the first look.

[orangy]

Guess the value of String.valueOf(null) expression in Java 😉

[ghedeon]

I stand corrected then. But I've seen a few times people redefining this behaviour to "" mostly in UI layer, because it makes more sense there. Anyhow, thankfully, custom extensions are easy to write.

[cbruegg]

But I don't like that functions may have nullable receivers. As extension methods are supposed to mimic instance methods, it's surprising this works.

[Burkhard]

I guess allowing null as the receiver of extension functions is a different discussion (and something that will probably never change). Anyhow I like it. Functions like isNullOrEmpty are great

[Ruckus]

As extension methods are supposed to mimic instance methods...

That seems a rather unfounded claim. Can you justify it?

[cbruegg]

Quite simply that at the callsite, they are indistinguishable from them.

[Ruckus]

There's a significant gap between sharing a common syntax and "supposed to mimic"

[cbruegg]

Fair point

[cbruegg]

Doesn't make my first time seeing this working less surprising though

[Ruckus]

I can see where you're coming from, but the distinction between member and extension (and their associated strengths and limitations) isn't just important, it's quite useful. @elizarov has a great overview of this in his "Extension-oriented design" article: https://medium.com/@elizarov/extension-oriented-design-13f4f27deaee

[Burkhard]

Also I don’t think there is a good way of avoiding that. Changing the calling syntax for extension functions would take away a lot of it’s power and probably end up like c++ with . vs ->.

[Ruckus]

@cbruegg There were quite a few things with Kotlin I found surprising when I first saw them working, but I never found that surprise detrimental. To the contrary, many of those surprises are precisely what make Kotlin such a pleasure to work with. They're "good surprises" if you will 🙂