What is the difference between Self types and F-bounded quantification? Does a first-class self type allow you to do something recursive type bounds cannot support? https://discuss.kotlinlang.org/t/self-types/371

Sometimes we need to preserve generic types in runtime, for example if we want to be able to distinguish between

Container<String>

and

Container<Int>

. A one particular solution (although not really flexible) would to subtype

Container<T>

with statically typed

StringContainer : Container<String>

and

IntContainer : Container<Int>

. The problem is, as aforementioned, it's not really flexible and we have to do it by hand. What if we could somehow tell compiler that we want to generate such subclasses with statically saved type parameter for every class that uses original, generic class? E.g.

open class Container<sticky T> {
  ...
}
...
val sc = Container<String>()
if (sc is Container<Int>) { // unreachable }

Under the hood would turn into

val sc = StringContainer()
if (sc is Container) { ... }

Theoretically, it is possible to track down all the types which generic type is parameterized with in compile-time; To avoid some problems with subclassing this functionality could be restricted for non-final classes. Also there could be problems with multiple type parameters. So, thoughts? Would this be useful, what more problems can this bring, is there ways to enhance it?

Not sure if this is exactly language design, but is there a specific reason why

@JvmOverloads

doesn't work in interfaces with default arguments? 🙂

C++ style generics -- new type creation C++(particularly 11+) template implement a meta-programming style which is well beyond java generics. With kotlin reified generics it may become feasible to implement some of the core concepts. Specifically the following: templates classes become new core types .e.g T<Int> and T<String> are compiled to different types with no relation. full compile-time resolution of generics to concrete types -- no need for workarounds to JVM Type Erasure as the types are fully resolved. Compile time overloading for templates type methods. e.g foo<Int>() and foo<String> are compiled into individual functions that can have different bodies. Compile time code generation/exclusion based on templates types. e.g. since types and methods compile to completely unrelated implementation you can provide completely different implementations for class and methods based on type alone. I realize the scope is large and deviates from Java compatibilty -- I am wondering if this style of generics was considered and if so what the results of the discussions. The cases for this are an extension to reified types -- If generics (or some similar language feature not replacing current generics) compiles templated types into distinct types, and related methods and classes as well are distinct -- then one can overload and specialize based on type. Classic example: (pseudo syntax in kotlin) // general case fun <T> sum( a: T , b: T) : T = a + b // specialized case fun sum<Cars>( a: Car, b: Car) = a.painted(b) fun sum<Double>(a: Double , b: Double) = _highlyoptimizedForDoubles( a , b ) Type specific singletons: class A<T> { companion object { val typeSpecific : T = T() // default init } } val A<Int>.Companion::typeSpecific : Int = 3 val A<String>.Companion::typeSpecific : String = "Three" fun <T> print( stuff: A<T> ) = println( stuff::typeSpecific ) Another valuable use case -- generic code that does not produce compile errors unless provided incompatible use. e.g. fun <A> shift( a : A ) = a shl 1 // only valid for integer types shift(1) // compiles no error shift("hello") --> Compile time error "shl undefined for String" val shifty = ::shift<String> --> compile time error My proposal is that this style of generics could be implemented as fully reified at compile time -- to non-generics. This would allow co-existence (while not great compatibility) with Java, and likely make implementation much easier. Conventions could be created as per the naming of the derived types such that it is predictable -- e.g. class A<T> , class A<Int>{} -> "A__java_lang_Integer"

Curious if anyone thinks it'd be a good idea to have a

@JvmBuilder

compiler plugin in the stdlib + Kotlin IntelliJ plugin that would generate synthetic members to make builders on `data class`es for use in Java. Using `data class`es with many properties is currently pretty clunky in Java. For example:

@JvmBuilder
data class Foo(val bar: String, val baz: Int = 0, val qux: String? = null)

should generate

Foo.builder()

that returns an object like:

public final class FooBuilder {
  public static FooBuilder builder() {
    return new FooBuilder().baz(0).qux(null);
  }
  
  // fields...

  public FooBuilder bar(String bar) { ... }
  public FooBuilder baz(int baz) { ... }
  public FooBuilder qux(@Nullable String qux) { ... }
  public Foo build() {
    // assert that properties with no default value were set
  }
}

data class Data(val a: Int)

Why

Data::a

does not return

KProperty<Data, Int>

by return

KProperty<Int>

? In first case we can write a function that receives only `Data`'s properties, something like

func process(prop: KProperty<Data, Int>)

Named arguments are really useful and makes code much easier to read, especially when you have to call functions that have many parameters. Unfortunately, named arguments aren't allowed when doing calls to Java for example. Since Java is also statically typed, is it not possible to make named arguments work with Java functions as well? Or would this be an issue when interopting with JavaScript? Proposal: allow calling Java functions from Kotlin using Named Arguments

Hi, my proposal is to allow braces-less `try`/`catch`/`finally` as done for `if`/`else`. Here's an example of how it could look like:

try registerAppInstance(info = AppInstanceInfo(
    someToken = someValue
)) catch (e: HttpException) ui.showError(
    when (val code = e.code()) {
        503 -> ServiceUnavailableTryLater
        ...
        else -> ...
    }
)

Proposal: Conditional assignment This is part of my quest to get

?

on more and more operators If a property is not null, it would be nice to have a conditional assignment operator that would assign a nullable value only if it is not null. For example:

map[KEY]?.let { value = it }

would become

value ?= map[KEY]

Edit As @Dico pointed out,

value ?= map[KEY]

can be a bit confusing, as it seems to imply

value

is the nullable item instead of

=

. It may make more sense to use

value =? map[KEY]

, but I'm on the fence.

just found this in a pull request:

val something = when(business) {
  //...
  someCase -> {
    POKOType.forName(name) ?: Log.warning("angry"); POKOType()
  }

If i had some kind of

@Pure

ref-transparent enforcement I could at least get this code tagged as suspicious, if not generate a compiler failure out right. whats the most aggressive thing I can do in my build system to catch this?

Constructors for Objects 🙏

lateinit on primitives

When creating classes that implement interfaces for use as delegates - it would be great to be able to mark them as incomplete and have compile-time error if the class using it as a delegate didn’t override any unimplemented methods. Is there a way to do that at the moment?

Since there's only ever one instance of an object the default identity equals and hashcode are fine, right?

does kotlin have it’s own version of IntStream.iterate ?

The next major version of Kotlin could automatically treat the "!!" operator either as warning or compile error, unless the particular line of code is annotated by

@IWantNPEToBeThrownHere

🙂. Or perhaps the compiler could have a flag to turn this behaviour on.

Would it be possible to have an option to pass the enclosing class as a weak reference to lambdas? Pretty much like swift does with

[weak self]

Further, any news regarding the package-protected visibility (https://discuss.kotlinlang.org/t/kotlin-to-support-package-protected-visibility/1544/55 and https://youtrack.jetbrains.net/issue/KT-29227)?

So basically make a file like an object? 🙂

Are there any plans to support Inline classes as annotation properties where the inline class wraps an allowed annotation property type. I have a personal use case with custom scripts backed by kotlin’s #scripting feature where at compile time I want strong type safety for the file:annotation arguments.

I was wondering if we could have sealed interfaces. A potential use case could be having the model for an application (let's say, type of posts on a social media platform). They can be represented as a set of sealed interfaces bit then have two different implementations depending whether they come from local cache, remote server or even dummies for testing... What do you peepz think?

You could have a sealed hierarchy of abstract classes

I'm pretty sure this isn't possible

We can work on a keep for that if it has enough acceptation. Also for passing custom error messages into RestrictSuspension annotation.

FWIW below compiles.

fun build(builder: (Context) -> View): View { TODO() }

val a = build(::View)

Any new informations regarding that? https://discuss.kotlinlang.org/t/sealed-class-inheritance-and-constructors/2283

KEEP-87 is ready to be submitted for consideration. A working prototype is in place with facilities to install as an IDEA plugin. The proposal has been reworded to simplify the examples and remove references to functional programming. The syntax has been reduced to existing Kotlin idioms and we are open to different approaches. In essence it brings the ability to group extensions functions as they are today in Kotlin under an interface that is parametric. The compiler then automatically resolves proofs the extensions are supported by a given type and activate the extension syntax and functions of the interface in whatever scope these extensions are required. This is essentially compile time verified dependency injection. The PR with the propossal is ready here https://github.com/Kotlin/KEEP/pull/87 and there is a fork in the Arrow org where the prototype has been developed by members of the 47 OS team and the help of some people involved with the Kotlin compiler which were kind enough to help us navigate its complexity. Please let us know if there is a better way to submit this or any additional things we need to do on our side so this is considered. This seems a welcomed feature by the community given the active participation in the KEEP and the many people involved with the prototype and proposal. I would like to state we are very much interested in the feature for both FP and OOP and not so much in the specific encoding so we are looking forward and are open to iterate on grammar, syntax or idioms all around. We are looking forward to the compiler teams opinions and other members of the community. If you got here thanks for reading this far and let us know if you'd like to get involved to make this happen in Kotlin.

Is that a right place/time to upvote multi-catch block proposal for Kotlin? https://youtrack.jetbrains.com/issue/KT-7128

We would like to start a discussion around enchanced ranges/slices and hopefully end up with a KEEP. Roughly the same set of questions is being regularly asked by people that come from a different language background: 1. Support for half-open range 2. Support for partial range (from, to, through) 3. Array/List slices. Possibly backed by before-mentioned ranges syntax. (all of this seem to be possible to implement without breaking changes in Kotlin) Currently, we propose to focus on the first one, in particular: adding

<

operator for

until

function. Gradually, having half-open and partial ranges, the slices syntax should follow. Given: Already implemented "closed range" in Kotlin. Since Kotlin range is closed by default, by likeness, Groovy and Swift might be considered as an inspiration: Closed range: Swift:

0...5

Groovy:

0..5

Half-open range: Swift:

0..<5

,

...<5

// compare to

val a = until 5 ???

Groovy:

0..<5

Slice: Swift:

arr[1...5], arr[1..<5]

Groovy:

arr[1..5]

====================================== Why it's important, why not

until

, why partial range? Personally, I believe that the closer we can get to the formal requirement (in this case — mathematical interval) the better. Thus, you don't execute the code but the requirement itself (it is only because of imperfection of our reality we're forced to write code around formal requirements 😉). That's why

+

is better than

plus()

. The former is essential and the latter is induced workaround. Also imho, with KISS in mind, there is no need to reinvent slices syntax (I've seen

:

proposal) when it's already covered by good range system. But it's a different discussion and I might be missing a bigger picture. Does

(1..<5)

look reasonable to you? cc: @Dico, @Mike, @karelpeeters, @Hullaballoonatic