kotlinlang #language-proposals

Join the conversation Join Slack

Channels

100daysofcode

100daysofkotlin

androidgithubprojects

cincinnati-user-group

competitive-programming

event21-community-content

java-to-kotlin-refactoring

jvm-ir-backend-feedback

kotlin-multiplatform-contest

kotlinultimatechallenge

myndocs-oauth2-server

naming

navigation-architecture-component

practical-functional-programming

proguard

prozis-android-backup

refactoring-to-kotlin

russian-kotlinasfirst

skia-wasm-interop-temp

stayhungrystayfoolish

swagger-gradle-codegen

tricity-kotlin-user-group

language-proposals

sanf0rd

03/12/2018, 3:50 PM

Exactly. My point is to make

when()

with enums as much expressive as it is with a

sealed class

benleggiero

03/14/2018, 3:48 PM

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

Aregev2

03/14/2018, 5:01 PM

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

guenther

03/15/2018, 6:13 AM

I'd like to be able to overload the

caret

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

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

)

Slackbot

03/15/2018, 2:46 PM

This message was deleted.

guenther

03/16/2018, 6:22 AM

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> = ...
}

benleggiero

03/19/2018, 2:37 AM

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

https://i.imgur.com/I7c9RMw.png▾

christopher

03/21/2018, 3:19 PM

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.

👍🏼 1

deviant

03/23/2018, 2:36 PM

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

➖ 6

cedric

03/25/2018, 10:30 AM

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

null

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

false

Fedor Bobin

03/30/2018, 7:51 AM

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

mekarthedev

03/30/2018, 6:53 PM

Anyone?

benleggiero

03/31/2018, 3:05 PM

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

Slackbot

04/01/2018, 9:46 AM

This message was deleted.

stephanc

04/16/2018, 1:06 PM

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"

➕ 2

👎 8

cedric

04/16/2018, 6:48 PM

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.

👍 1

poohbar

04/16/2018, 6:52 PM

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.

☝️🏼 1

stephanc

04/17/2018, 7:29 AM

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

👎🏼 2

stephanc

04/17/2018, 8:28 AM

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

poohbar

04/17/2018, 12:13 PM

@karelpeeters I often resort to

!!

.min()

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

karelpeeters

04/22/2018, 11:22 AM

list?[6]

would be cool as well.

👍 1

poohbar

04/26/2018, 8:31 PM

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

sendilkumarn [JHipster]

04/30/2018, 2:04 PM

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

web assembly

karelpeeters

04/30/2018, 4:59 PM

You could even add an extension property

.int

if the standard way is too long.

eddie

05/01/2018, 4:31 PM

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

guenther

05/05/2018, 5:46 PM

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

guenther

05/05/2018, 6:09 PM

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%

🤔 1

Caleb Allen

05/07/2018, 10:47 PM

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

benleggiero

05/08/2018, 4:16 AM

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.

benleggiero

05/10/2018, 3:05 AM

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 :thread-please: comments here would be greatly appreciated!

👍 3

Title

benleggiero

05/10/2018, 3:05 AM

👍 3

I’m going to sleep right now, but I will read every comment given 🙂

karelpeeters

05/10/2018, 7:22 AM

I'm kind of confused: where does the

operator fun sequenceLiteral

go? Top-level somewhere?

voddan

05/10/2018, 9:08 AM

val b2 = [1, 2, 3] as MutableList<Int>

Something tells me this reuse of the

as

operator will not go well with JB guys

rrader

05/10/2018, 9:38 AM

takesAmbiguousType(["1", true, 3] as Set<Any>)

how this is better than

takesAmbiguousType(setOf("1", true, 3))

nish

05/10/2018, 5:00 PM

I think that the lack of clarity in situations

[["foo"] : ["bar", "baz"]]

like this outweighs the risk of mistaking

{ ["foo"] : ["bar", "baz"]  }

for a function

Since a lot of other languages use curly braces for dictionaries and maps, there’s the element that a nice chunk of developers have already been trained to understand the syntax

benleggiero

05/11/2018, 12:19 AM

@karelpeeters Yes, as the document says, “This must be implemented via a top-level function.” I had originally said that it can also go in the companion object of the type it applies to, but there was pushback on that and it would be a little more difficult for the compiler and less elegant to import.

@voddan It’s not a new use. It’s precisely the same as if, today, you write a non-operator version of the

syntaxLiteral

and called it like this:

val b2 = syntaxLiteral(1, 2, 3) as MutableList<Int>

@rrader That’s a great point! In that exact scenario it’s not more terse, and one can easily argue it’s not more expressive. But note that to specify another of the ambiguous types, one need only change the type after

as

. This applies to custom collections and generic types, too. All this while keeping the exact syntax of the sequence the same, something that isn’t really possible with the

___Of(

syntax

@nish Great point! It is a little unclear with all the square brackets flying around. That said, it’s not exactly more clear today with all the parentheses. I will add this to the document, but another reason I chose the brackets is because they always mean “I’m using a collection”. Today,

foo[bar]

means “I’m accessing an item in a collection”,

foo[bar] = baz

means “I’m changing an item in a collection”, and

@foo([bar, baz])

means “I’m creating and passing an array collection to this annotation”. I am continuing this pattern by showing that

[ foo : bar, baz : qux ]

mean “I’m creating a dictionary collection”, furthering the enforcement that square brackets mean collections. Additionally, currently, curly braces mean scope. When there is an opening curly brace, you are entering a new scope and can take outer things in, and when there is a closing curly brace, the scope ends and everything local to it is destroyed. Utilizing curly braces as dictionary delimiters muddies this concept, because by definition, everything in that dictionary is persisted and passed somewhere.

Thanks for all the great critique! It’s wonderful to hear 😄

ilya.gorbunov

05/11/2018, 2:39 AM

I presume there will be a

sequenceLiteral

operator defined for each of the standard collections, e.g.

List

Set

Array

Sequence

. Now consider the operator functions like

on collections that have overloads for different combinations of the first and second parameter types — using collection literals as their parameters would be inherently ambiguous. What overload did I mean in this expression:

collection + [element1, element2]

? Is it

Iterable + Array

, or

Iterable + Iterable

, or

Iterable + Sequence

benleggiero

05/11/2018, 3:16 AM

That’s what I recommend in the Changes to stdlib section: https://github.com/BenLeggiero/KEEP/blob/collection-literals/proposals/collection-literals.md#changes-to-stdlib It should basically be a one-to-one replacement/augmentation. Correct, it is ambiguous. It is equally ambiguous as having said

collection.plus(sequenceLiteral(element1, element2))

. As with the entire rest of the language, you will have to differentiate it somehow, be it with

as

, by saving the collection to an explicitly-typed variable first, etc. I addressed this in the comments of the original gist: https://gist.github.com/BenLeggiero/1582a959592cadcfee2a0beba3820084#gistcomment-2547629

ilya.gorbunov

05/11/2018, 4:35 AM

For the same reason you won't be able to call

map

filter

etc on a collection literal, without casting it first.

voddan

05/11/2018, 7:54 AM

If 'as' in this context is simple casting, it ether won't allow optimising for immutable data, or it will crash half the times

benleggiero

05/12/2018, 4:14 AM

@ilya.gorbunov @voddan I don’t think it’s casting… in my head casting is something that happens at runtime. This is typehinting for the compiler.

Also, @ilya.gorbunov, why? I don’t see why

sequenceLiteral("1", "2", "3").map { it.toInt() }

won’t work. Which means

["1", "2", "3"].map { it.toInt() }

would work as well

ilya.gorbunov

05/12/2018, 4:23 AM

What is the type of collection literal expression here? Is it List? Is it Sequence?

benleggiero

05/12/2018, 5:35 AM

As stated in the proposal draft, the default type if none is specified would be a List whose generic element type is inferred, just like

listOf

ilya.gorbunov

05/13/2018, 11:56 PM

@benleggiero From the type inference perspective

[1, 2, 3].map { }

case isn't different from

takesAmbiguousType([1, 2, 3])

and the proposal says the latter should be resolved with casting. It's an interesting idea to default to List/Map even for ambiguous expected types, but it should be examined with care, whether it could introduce unintuitive consequences. Please either treat the ambiguity consistently in the parameter and receiver positions (and decide how should it be treated), or list both options in the "open questions" section of the proposal.

benleggiero

05/14/2018, 12:13 AM

@ilya.gorbunov I would expect

[1,2,3].map {}

would map a

List<Int>

, since that is the default type of a sequence literal. So it would be exactly the same as

listOf(1,2,3).map {}

Maybe I should give examples, but I was imagining that

takesAmbiguousType

as an overloaded method, with one taking maybe a Set and another taking maybe an Array (the exact types don't matter as long as none are

List

), so the default type is not applicable

ilya.gorbunov

05/14/2018, 12:14 AM

.map

extension is also overloaded for multiple receiver types (neither of them is List, the closest one is Collection or Iterable)

benleggiero

05/14/2018, 12:28 AM

I understand this. My perspective is that, since

map

clearly applies to the default type, but the default type doesn't apply to

takesAmbiguousType

, this is why casting and other type hints aren't necessary in the map example, but are in the ambiguity example. I'll note this in the proposal

karelpeeters

05/14/2018, 12:33 AM

But that breaks the symmetry between a receiver parameter and normal parameter, right?

benleggiero

05/14/2018, 12:34 AM

I am on my phone, but when I get back I'll write an example that will hopefully clear this up

Here is a better illustration of what I am going for:

fun takesAmbiguousType(x: Set<Int>) {}
fun takesAmbiguousType(x: Array<Int>) {}

takesAmbiguousType([1, 2, 3]) // Error: cannot resolve type; default sequence literal type List<Int> does not match any candidates
takesAmbiguousType([1, 2, 3] as Set<Int>) // OK
takesAmbiguousType([1, 2, 3] as Array<Int>) // OK

val y: Set<Int> = [1, 2, 3]
takesAmbiguousType(y) // OK



// Defined in stdlib: public inline fun <T, R> Iterable<T>.map(transform: (T) -> R): List<R> 

public inline fun <T, R> map2(x: Iterable<T>, transform: (T) -> R): List<R> { /* ... */ }


val z = [1, 2, 3] // Inferred type is List<Int>

z.map { it.toString() } // Maps List<Int> to List<String>
map2(z) { it.toString() } // Maps List<Int> to List<String>

[1, 2, 3].map { it.toString() } // Maps List<Int> to List<String>; no type is given but default type List<Int> matches a map candidate
map2([1, 2, 3]) { it.toString() } // Maps List<Int> to List<String>; no type is given but default type List<Int> matches a map2 candidate

ilya.gorbunov

05/14/2018, 2:58 AM

Note that

map

has a couple of overloads, e.g. with

Array

and

Sequence

as receivers. Does it change the resolution result in the example above? If it doesn't, consider the following overloads:

fooAnyOrSet(param: Any)
fooAnyOrSet(param: Set<*>)

fooAnyOrSet([1, 2, 3])

Is it an expected behavior that the first overload is selected in this case?

gildor

05/14/2018, 10:43 AM

recommends that these existing functions be marked as deprecated

I am absolutely against such proposal about deprecation of existing builders, it’s not clear how this change can improve language and no clear why we should do that, for example not clear what to do with method references to those methods

benleggiero

05/15/2018, 2:33 AM

@orangy I would expect that to pass a

List<Int>

fun fooAnyOrSet(param: Any)

, since the default type matches it

@gildor That’s fine. It wasn’t a sticking point for me, which is why I used the word “recommend”. That said, what do you mean “method references to those methods”? Does deprecation affect those at all?

gildor

05/15/2018, 2:38 AM

Imagine such code:

val list: List<String> = "some string".run(::listOf)

How can I do that without builder functions using only literals? If builders would be deprecated this code will be marked as deprecated too

benleggiero

05/15/2018, 3:26 AM

That’s a good point. One day I’d like to see a way to pass constructors as function references… maybe that’s not possible on the JVM without weird wrapping workarounds

ilya.gorbunov

05/15/2018, 4:31 AM

You can get a function reference to a constructor even now:

list1.zip(list2, ::Pair)
// or
".+".let(::Regex)

:kotlin-flag: 1

🤩 1

gildor

05/15/2018, 4:50 AM

Problem with constuctor, that List doesn’t have one, it’s an interface. And

listOf

hides implementation details, so you cannot do something like

::List

, only

::ArrayList

, but it’s not what you wait from list builder

👍🏼 1

udalov

05/15/2018, 3:35 PM

@gildor

"some string".run(::[])

:trollface:

🙈 3

😄 1

voddan

05/15/2018, 5:40 PM

👆 totally not like Scala 😒cala: :trollface:

😂 1

@benleggiero I think your draft and these comments have tremendous value, either paving the way for construction literals, or demonstrating all the problems with the feature. Regardless of the outcome, I think we need to preserve the draft and the discussion for future use. Unfortunately the discussion happened on Slack, not on GitHub (as it should have been, according to KEEP rules). Could you please go for the trouble of publishing your draft to KEEP repo (all of its major iterations) and the comments (at least the major points in the discussion). I may offer my help with the routine tasks or editing.

💯 1

➕ 1

ilya.gorbunov

05/23/2018, 1:02 PM

@benleggiero Kind reminder that this thread will soon vanish under message event horizon, so if you want to evacuate something useful from it to KEEP, it's time!

benleggiero

05/23/2018, 1:37 PM

Thanks, @ilya.gorbunov! Archived here: https://imgur.com/a/NKw0MCF

voddan

05/24/2018, 6:52 AM

@benleggiero on Imgur it is not text, thus it is not searchable, making it useless. I strongly recommend saving all to Github.

benleggiero

05/25/2018, 12:54 AM

@voddan Sure thing, when I have time. That's the quick thing I could do while mobile. Not much time at desktop these days.

View count: 4