thoughts on having argument labels like in swift? https://docs.swift.org/swift-book/LanguageGuide/Functions.html#ID166 I can see it being helpful in dsl design but I haven't used them.

Any particular reason why

iterator

in

Iterable

is a method, not a property?

Is there a proposal about union type, like in Ceylon, if so, can you please send the link?

Heys guys, are there any plans to have a

pattern matching

feature like other languages have like Elixir?

I'm curious why this works

fun a(): Unit

==

fun a()

but this doesn't:

fun b(G: Unit)

!=

fun b()

This message was deleted.

What about making frozen-ness a part of type, much like nullability is? Maybe a

#

at the end to indicate that you expect a mutable thing rather than a frozen thing. I haven’t thought this all the way through yet. There might be some big problems with that. I just see immutability issues being a huge problem for Kotlin Native in the future unless we have some language features to prevent some common issues.

suggestion: allow trailing commas to be optional (same way ; can be noise punctuation), the following code should compile, and behave the same way as if the last comma were not present

val modules = listOf(
    "ph-db-migration",
    "ph-emr-entity",
    "ph-emr-event-type",
    "ph-events",
    "redox",
)

you probably wouldn’t write this like this, but it makes the last comma more obvious

val modules = listOf( "ph-db-migration", "ph-emr-entity", "ph-emr-event-type", "ph-events", "redox",)

would compile to the same thing as

val modules = listOf( "ph-db-migration", "ph-emr-entity", "ph-emr-event-type", "ph-events", "redox")

suggestion: full support for traits. Syntactically I feel like kotlin already does with interfaces, but interfaces cannot have state currently, a trait on the other hand can store state but can't be instantiated (outside of anonymous class... ) itself. I actually thought kotlin had this, because you can put a val in the interface, however I didn't realize you'd then have to override that in the composing class. Basically I want support for Perl 6 Style role's except statically typed.

suggestion: support private/protected keywords on interfaces protected would mean accessible by anything that extends/implements the interface via this.

Suggestion: toString of an object declared with an

object

expression should return the object’s name without the ‘@<id>’ suffix.

Re-posting here for visibility:

Kotlin should automatically choose lambda expressions with a single argument over multiple arguments for the implicit case. You should not need to specify an explicit lambda signature in order to use

it

when competing overloads all have higher arity.

https://github.com/kotlintest/kotlintest/pull/506#issuecomment-451624300

Has there been any discussion around inline classes and having them conform to a contract similar to enums? For example, it'd be nice to be able to generify over the ability to wrap/unwrap. With enums I can bound a generic on

: Enum<T>

which (combined with

inline

) lets me do

T -> String

and

String -> T

conversion. It would be nice to achieve similar

T -> V

and

V -> T

conversions with an inline type (where

V

is the property type) in a generic way. Right now I'm using a factory where you have to pass

::Foo

and

Foo::property

as arguments which leaves a lot to be desired.

I have it sooo often that I have to unwrap inline classes, do some basic operation and then wrap it again. That’s quite annoying and you can change the result to a different inline class without even noticing.

You’d still have to type safety to not assign a

Username

to an

EmailAddress

for example.

Your "transparent inline class" is called

typealias

😉

Hi. Very quick question. Is there any KEEP or proposal to introduce something like clojure keywords in kotlin?

@Roman, my Person and your Person will not compose, even if both have the same exact name and date params as their constructor params

Jake, well even now I can write as my example, define enums and strings, and use them as keywords... but keyword concept is a bit more - it defines and uses at the same time and it evaluates to itself, or is a function

In Scala you can destruct a type with pattern matching. It comes quite handy when we have to work with containers. An example to it is:

def listToString(list: List[String]): String = list match {
    case s :: rest => s + " " + listToString(rest)
    case Nil => ""
}

would it make sense to add a similar pattern matching for the destructuring declaration? the example above could be replaced with `fold`/`reduce` and mixing it with

windowed

but if the list length is zero we would get an exception

java.lang.IndexOutOfBoundsException: Index: 0, Size: 0

with pattern matching this could be automatically run to the

case Nil => ""

. The compiler also could check for unsatisfied cases just like it does right now when we match agains for enum or sealed class types

Random idea: When removing the

package

directive from all Kotlin files of a project then a compiler option allows specifying the same package name for all Kotlin files instead of using the root package. So I can stop repeating myself.

hmm... idea, keyword

test

on a class makes the class internal, and so that you can't directly call any constructors. on a method it would make it internal (is this a thing for a method?). Motivation, avoid ID10T errors involving trying to new up the test in your code, vs trying to new up the class under test 😕 also the internal keyword is long and test reads better.

Proposal: Allow a training

=

on any var infix function that returns the receiver's type (or compatible):

// Current
var superAwesomeNumber = 5
superAwesomeNumber = superAwesomeNumber shl 3

// New
var superAwesomeNumber = 5
superAwesomeNumber shl= 3

It would be nice for long chains of bitwise operators, but it could also be nice for any infix function. It is especially appealing when you use very descriptive names.

Rust’s new

dbg!()

macro looks pretty useful, I was wondering if it would be possible to replicate it in Kotlin. This would require being able to capture the text form of the expression. https://blog.rust-lang.org/2019/01/17/Rust-1.32.0.html

It's also very expensive.

what about

@JvmOverloads

on interface methods?

Would extension fields be feasible? As in actual storage and retrieval of a value? On the JVM it could use some form of WeakHashMap backing it. Not the default implementation, as it won't clean up after itself properly, but maybe something using PhantomReference. For JS it could actually just use a property I dunno about Native. It could be useful in cases where you want to "tag" an object with some data, but only want that data around as long as the object.

I know this is probably specific to my use case only, but it would be mighty nice if I could instantiate an annotation class in common code. I’ve written an external reflection plugin and library, and have to use an awkward wrapper around annotation information because I can’t just instantiate the annotation class itself.

This message was deleted.