3 ms·
I wonder if that confusion is due to the fact that you haven't yet wrapped your head around the fact that extension functions are "just" syntactic sugar for sta
by simon_void 1y ago
I wonder if that confusion is due to the fact that you haven't yet wrapped your head around the fact that extension functions are "just" syntactic sugar for static functions. The implicit "this" becomes the the first parameter of the static function and function parameters can be null. Now you might ask "why not use static (/first class) functions then? Because those "feel" like less ideomatic to use then extension functions or methods that are defined on the object (hirachy) itself.
But understanding why the extension type can be nullable is not the same is using it on nullable types. I restrict my extension functions to non-nullable types most of the time as well. The best exception to this preference -just to see where it makes sense- is the build-in function [toString](https://kotlinlang.org/api/core/kotlin-stdlib/kotlin/to-string.html https://kotlinlang.org/api/core/kotlin-stdlib/kotlin/to-stri...), since you want it to return "null" if you invoke it on null.
- vips7L 1y agoI have wrapped my head around it. I think it's confusing to the reader and creates awkward semantics.
- vips7L 1y agoWhat I mean by that is this: val a: SomeType? = null // I’m forced to null check here if (a != null) { a.someMethodOnIt() } // But I don’t have to null check here a.someExtensionFn() It’s weird.
- izacus 1y agoYeah, extension functions are one of those features that went from 'oh, this is nice' to "this is so overused it's counterproductive". It makes reading a lot of Kotlin source quite terrible. Lately they've been shoveling a lot of similar magical "code comes from somewhere" features into a language, slowly giving it a C++ clutter type feel.