right

this is actually one reason why I argue that an

Option

type can still add value, even in Kotlin with null safety baked in 🙂 But I understand not everyone shares that opinion

i.e. it provides an "absence context" more clearly

there are definitely pros and cons to both. The fact that

T

is a subtype of

T?

lends itself to a lot of elegance in Kotlin in my opinion. This is clearly a situation where it would have been nice to declare this function on

Option<T>

There is, actually: the deprecation with

ERROR

level. This, however, doesn't exclude an extension from resolution.

@User uploaded a file: Untitled

Though I guess it's closer to a hack than to a good practice in API design. 🙂

whoa, that's interesting, but definitely a bit of a hack 😛

never would have thought to do that

@User uploaded a file: Untitled and commented: some of extensions I use in my projects

too small to report as feature, too diverse to make a lib

thanks for sharing @h0tk3y, interesting idea.

nullIfNot

is in fact

kotlin.takeIf

@ilya.gorbunov commented on @aimozg’s file https://kotlinlang.slack.com/files/U0BMADWBS/F3WPZT6MT/stdlib_extensions.kt: Interesting. What are use cases of

GetterOf

?

@aimozg commented on @aimozg’s file https://kotlinlang.slack.com/files/U0BMADWBS/F3WPZT6MT/stdlib_extensions.kt:

class UserCan(internal val me: User) {
	val user = GetterOf<Long?, UserHelper> { UserHelper(it) }
	val anyUser = UserHelper(null)

	fun view(s: Subscription): Boolean {
		if (s.user_id != null && s.user_id == me.user_id) return true
		if (user[s.user_id].viewLog) return true
		 /*... */ return false
	}
}

@aimozg commented on @aimozg’s file https://kotlinlang.slack.com/files/U0BMADWBS/F3WPZT6MT/stdlib_extensions.kt: basically, it allows you to replace

obj.prop(index) //=value

with

obj.prop[index] //=value

@robin commented on @aimozg’s file https://kotlinlang.slack.com/files/U0BMADWBS/F3WPZT6MT/stdlib_extensions.kt: Do you have a real world example? I'm not quite sure on why you would want to just switch from parens to brackets...?

@robin commented on @aimozg’s file https://kotlinlang.slack.com/files/U0BMADWBS/F3WPZT6MT/stdlib_extensions.kt: Oh and also, is that definition with the separate interface and function any different from this?

class GetterOf<in K, out V>(val func: (K) -> V) {
    operator fun get(key:K) = func(key)
}

@aimozg commented on @aimozg’s file https://kotlinlang.slack.com/files/U0BMADWBS/F3WPZT6MT/stdlib_extensions.kt: As for why I want to switch to brackets - it looks like a collection access, but I don't need to expose whole collection

@aimozg commented on @aimozg’s file https://kotlinlang.slack.com/files/U0BMADWBS/F3WPZT6MT/stdlib_extensions.kt:

val x = obj.propertyValue(PropertyTypes.ENUM_1)
val y = obj.properties[PropertyTypes.ENUM_1]

@aimozg commented on @aimozg’s file https://kotlinlang.slack.com/files/U0BMADWBS/F3WPZT6MT/stdlib_extensions.kt: Don't have any better examples.

@aimozg commented on @aimozg’s file https://kotlinlang.slack.com/files/U0BMADWBS/F3WPZT6MT/stdlib_extensions.kt: I think I've left the interface separated in case I'll need to use it as a type parameter. Never needed though.

@robin commented on @aimozg’s file https://kotlinlang.slack.com/files/U0BMADWBS/F3WPZT6MT/stdlib_extensions.kt: Ah I see, with the rename from

propertyValue

to

properties

the semantics are clearer this way.

Is it normal that

””.split(” “) == arrayOf(””)

? I would expect an empty array

split

was modeled after Python's

split

(because the Java's one is creasy)

So yes, this is "as designed"

I figured. Pretty counter intuitive though

Ether way would be counter intuitive 😞

Not convinced about that. If you run a survey, I bet most people would expect an empty array as a result