Exactly. My point is to make

when()

with enums as much expressive as it is with a

sealed class

I actually have a draft brewing about that. I'll put it on GitHub gist later

Are there plans to implement LinkedList and TreeMap to kotlin? (or there are alternatives)

I'd like to be able to overload the

caret

. Is there anything against this? (e.g.

operator Int.caret(x: Int): Int = Math.....

)

This message was deleted.

Would it be possible, to make the

Class::function.name

literal a compile-time-constant? This would really help in situations where a name for an annotation is actual a function-name like in JUnit-Parameterized-Tests:

object CalculatorTest {
    @ParameterizedTest
//  @MethodSource(value = CalculatorTest::multiplyNumberProvider.name) // HERE IT WOULD HELP
    @MethodSource(value = "multiplyNumberProvider") // this sucks
    fun `multiplication of two numbers (with params)`(num1: Int, num2: Int, expected: Int) {
       ...
    }
    fun multiplyNumberProvider(): Stream<Arguments> = ...
}

I have no idea what compiler changes are necessary, but I see no reason why we can’t have fully-Unicode identifiers.

Interesting video related to language development popped up on reddit today: http://reddit.com/r/java/comments/85zeib/stewardship_the_sobering_parts_by_brian_goetz/. Thought it might prove enlightening.

created a ticket about [] operator https://youtrack.jetbrains.com/issue/KT-23388

@kingsley I don't understand your point with the snippet of code above. Considering

null

as

false

is pretty intuitive. Kotlin by design avoids implicit conversions as much as possible, which is why that code is invalid but I don't think it would lead to bugs or hard to read code to silently convert a

null

Boolean

to

false

--- cross-post from #general ---- Hello. I am trying to use ktor-clients that use reified generics to handle return type and pass it to deserialization routine.

httpClient.get<Type>(...): Type <------ return type is handled from reified generic parameter
  
interface JsonSerializer {
suspend fun read(type: KClass<*>, content: IncomingContent): Any <<------ and handled type is used to instantiate object
}

If I pass List<MyObject> as a type parameter, I silently get List of garbage because reified generics does not include inner parameters and only List<*> will be passed to JsonSerializer.read(...) I am wonder why not: 1) either: do not allow to pass classes with inner generics to reified methods 2) or: pass something different then just KClass that supports chain of generics

Anyone?

That's not a language proposal. Perhaps ask in the #getting-started channel

This message was deleted.

I had a thought yesterday, what if there was something like a super elvis operator, for cases where there are many safe calls, but this feature is probably too overkill. 😛 For example, rather than this:

bob?.department?.head?.name ?: "meh"

There is something like this:

bob.department.head.name ??: "meh"

What I dislike about the super elvis idea is that it’s no longer clear to me which of these variables can be

null

. I understand that’s the point of the operator, but I think it drifts away from Kotlin’s approach of staying away from implicit behaviors.

In some languages (C#) the

?.

operator actually works similarly. You do not have to repeat the question mark in the rest of the chain. I thought the Kotlin approach was annoying at first but now it makes more sense to me than the C# approach and I have no need for a super elvis either.

So I had another thought yesterday. lol. on this super elvis operator. The example I gave isn't really where it would be able to shine, if this was implemented to catch any null within an expression and propagate it through that operator. In this case, it is syntactic sugar for catching null reference exceptions more elegantly. An example I thought about is when you are calling a java method via kotlin and there is a null being thrown inside somewhere, then that operator will take care of it. So rather than ?: checking the null at the end of an expression, ??: will check any null within an expression. So in a sense it is a wrapper. In that case, it wouldn't have to change any behavior of

.

@dalexander

@karelpeeters lol, but some people just convert their java code and don't change anything 😛. But yeah, we shouldn't give too many tools that can be abused. Thus, the super elvis operator opens pandora's box too much and is way too overkill. However, it isn't completely clear from the kotlin docs that kotlin's safe call is not like C#'s null propagation. So in Kotlin you will have to write a few extra

?

, at least there is scoping functions as well that limits this.

@karelpeeters I often resort to

!!

on

.min()

or

.max()

calls where I know the collection is not empty. I kind of wish we had a

NonEmptyList

that would return non-nullable types from such functions. Do you guys have a better way to handle this?

list?[6]

would be cool as well.

tbh I am not a huge fan of exploiting extension properties this way either, but I get where people are coming from

Is there any POC or trials made to make Kotlin compile into

web assembly

You could even add an extension property

.int

if the standard way is too long.

Reading about frozen objects in Kotlin/Native 0.7 reminded me about Pony’s reference capabilities. Have those been looked at in any capacity to see how they might inspire some future Kotlin features? https://tutorial.ponylang.org/capabilities/reference-capabilities.html

Extension delegation properties It should be possible, to extend a

class

with an

extension property

using delegation. Of course only, when the delegated object (in this case the map) is accessible.

class Foo(val map: MutableMap<String, String> = mutableMapOf()) {
    var bar1: String by map
}
var Foo.bar2: String by map

Number Dimensions I'm currently investigating the Kotlin-CSS-Wrapper (https://github.com/JetBrains/kotlin-wrappers/tree/master/kotlin-css), and during migration of my CSS to that wrapper, I experienced, that using this DSL has some drawbacks over plain CSS: Dimensions of Numbers cannot be written that well as with plain CSS. So it would be really useful to have the possibility for giving a Number a dimension like this:

dimension val Int.px: MyDimensionedNumber  get() = MyDimensionedNumber(this, "px")
dimension operator val Int.unaryRem: MyDimensionedNumber  get() = MyDimensionedNumber(this, "%")

Then instead of using things like:

100.px
100.pct

This can be done:

100px
100%

I asked this in random but wondered if this was a more appropriate place to propose this: enforcing handling of a sealed class using method overloading. For example:

class ResponseHandler{
    fun handle(success: Response.Success) {}
    fun handle(error: Response.ErrorB) {}
    fun handle(error: Response.ErrorA) {}
}

fun getResponse(): Response{
    val r = Random()
    return when (r.nextInt(3)) {
        0 -> { Response.Success() }
        1 -> { Response.ErrorA() }
        2 -> { Response.ErrorB() }
        else -> { throw IllegalStateException() }
    }
}

And then calling

ResponseHandler().handle(getResponse())

This will not compile. The same effect can be achieved using if I implemented a method taking a

Response

parameter like so:

fun handle(response: Response) = when (response) {
        is Response.Success -> { handle(response) }
        is Response.ErrorA -> { handle(response) }
        is Response.ErrorB -> { handle(response) }
    }

Is it possible for the compiler to resolve the type for me? Given that all possible types are handled, similar to

when

I don’t know of any Kotlin language-level features that require an external build system. Yours would be the first, so expect a lof of push-back from that angle.

First draft of collection literals proposal done. You can view it on my GitHub here: https://github.com/BenLeggiero/KEEP/blob/collection-literals/proposals/collection-literals.md Tomorrow I will start going over it and refining it to become a final draft before submitting a pull request. Any 🧵 comments here would be greatly appreciated!