I love keeping (get it) track of all the suggestio...

# language-proposals

[jkbbwr]

I love keeping (get it) track of all the suggestions and changes, I just hope that kotlin doesn't change for the sake of change. It'd be bad to lose its way and just keep adding things

[poohbar]

My thoughts exactly. I think the feature creep is becoming a problem with Kotlin. At this pace, we will have another Scala disaster on our hands in a few years.

Why is it so hard to resist adding unnecessary crap into something that works just fine?

[benleggiero]

I mean, my fully-fleshed-out proposals, which I think would add really great stuff to the language and reduce boilerplate, were scrutinized and never picked up.

So.. they're certainly resisting adding "unnecessary crap"

[benleggiero]

@poohbar what kind of additions do you think are "unnecessary crap" which got put into the language?

[poohbar]

Which proposal do you mean? The collection one?

I think having both type aliases and inline classes is a bit messy for newcomers. It makes sense for people following Kotlin as it grows but years from now people will be confused as to why the language has both.

I think the rules around inlining properties and functions are too complicated and confusing.

Basically, in general, I think Kotlin is feature-rich as it is and they should slow down with the additions just a bit.

That being said I welcome extending the standard library with things like .windowed and .chunked. That never hurts anything because it does not add any new concepts to the language.

[gildor]

Incline classes and typealiases are very different after all, and other languages have similar concepts of typealiases (no runtime check, just new ne for existing class),for example haskell and scala have keyword type which is typealiase definition

[benleggiero]

I also authored a proposal for having language-level error handling which included compile-time warnings/errors. It was... shot down, to be kind.

I'm thinking of a better one, and taking much more time on it

https://github.com/Kotlin/KEEP/pull/81

[poohbar]

@gildor I definitely would not take inspiration from Scala which is riddled with deprecated features that nobody should use anymore.

[poohbar]

@benleggiero The error handling proposal was also not a great idea imho.

[gildor]

Yes, Scala is not the best example, but still it's pretty simple idea to have an aliases for existing types without runtime penalty.
Incline classes from other view is performance optimization for different cases.
I don't think that it would be somehow hard to explain for newcomers

[eddie]

@gildor I view inline classes as mostly being a workaround for the limitations of the JVM. Had Kotlin targeted native platforms to begin with, classes themselves would likely be represented internally more like structs/classes in C/C++.

[gildor]

I don't think that classes would be represented as structs. Classes have identity and if Kotlin would be originally target native and decided to support structs that would be a separate feature of language rather than some class optimization, this is also true for other languages such as C++ or Swift.
And value types will be probably available in the future, when it would be clear how they will work on JVM and Project Valhalla

[eddie]

the members of C++ class objects are inlined by default just as they would be in C/C++ structs

[gildor]

Inlined? But members of JVM class also part of class. Or mean something different?
In case of class you still should keep object identity somewhere.
And actually this is not relevant to original statement. Class optimisations on runtime are just implementation details, but struct (and inline class as simple 1 field struct) has different semantics, no identity, only data. And again, it is separate language feature even on C++

[eddie]

I’m referring to the “fields” of a class or struct, in the case of C++, both classes and structs allocate memory for members inline with the containing object

[gildor]

This is also true for JVM class

https://3.bp.blogspot.com/-bFk6fuNhRSY/V9xqibxnA1I/AAAAAAAANoo/zDF_pg-CdOkLg-KLTVTWZ8Y4_EmHulObACLcB/s1600/java%2Bobject%2Blayout.png▾

[eddie]

right, for primitives

[gildor]

Yes, as I mentioned before, for primitives

[gildor]

Do you want to say that C++ classes inline even enclosing classes? Maybe, but again, it looks like different semantics, you just cannot than keep reference to internal object (like create an object, save reference and than pass it to another class constuctor)

[eddie]

Yes, sorry - that’s what I’m getting at. The storage for members is enclosed within classes & structs. Technically speaking I suppose the same is true with JVMs, but the difference being that the JVM requires non-primitive fields to be references to some other place in the heap.

[gildor]

But how this work? So you have one object, you create it separately. So runtime should allocate memory for this object. Than you passed this object to another class constructor where this object storied in a field. Will in this case runtime allocate memory again for this object? Doesn’t sound as an efficient solution, 2 times more memory consumed, even if you have data locality. Also what if original object had mutable fields, how you can update it?

[gildor]

In case of JVM class keeps just a reference to another class, so no problems with it

[eddie]

well in C/C++ the object might be created on the stack without heap allocation, so you wouldn’t have the extra memory consumption (and if you wanted to copy in an object created on the heap you’d likely be freeing the object afterwards)

[gildor]

JVM also have escape analysis and stack allocation.
But it’s not always possible, and I can easily imagine case when runtime can allocate object only in heap for very common cases, so it should be some more sophisticated logic under the hood

[jkbbwr]

Just so you know, inline classes are a wonderful idea. Simple to explain and powerful. Im not worried about inline classes. I just made that comment because I had a fever dream of kotlin turning into scala

[benleggiero]

Nobody here wants Scala 😛

[eddie]

I guess my point is that Kotlin doesn’t really give you the power to decide where to allocate memory like C would, but I come from a C background so that’s just what I’m used to.

[benleggiero]

I mean if you like C, it'll always be there! Kotlin is proud being a high-level language that abstracts away memory management

[eddie]

very true

[eddie]

don’t get me wrong, I prefer Kotlin over C in just about every other area, heh

[themishkun]

@benleggiero your error handling proposal was shot down because it can already be implementing using Either or Try equivalents from Scala, there is no need in special syntax for that

[benleggiero]

@themishkun I'm not sure I understand... I don't think Scala's Try or Either are in the Kotlin language or stdlib 🙃

[themishkun]

@benleggiero you can take arrow-kt for that

[benleggiero]

@themishkun Sure.. but this is a language proposal, not a use-another-library proposal. I intend to attempt to make using Kotlin better for everyone, not just for those who use library dependencies

[gildor]

Try and Either don't require any language changes and can be implementated as library classes.
1.3 has SuccessOrFailure (which according to last commits will be renamed to Result), and this class is actually very similar to Try

[benleggiero]

I also wanted a better way to handle interacting with existing libraries, like Java SE, which throw errors all the time. Ironically it's a better experience right now in Java because the compiler forces me to explicitly handle a checked exception. Kotlin won't let you know if you're using a function that can throw a checked exception at all, unless it's annotated with @Throws and you turn on a specific compiler warning.

[jkbbwr]

The more that can be added to kotlin by library the better. It keeps the main language noise free and simple while providing community drive for the best solution as they will naturally win over time.

[jkbbwr]

The perfect example imo is coroutines. The fact that this is basically just a library is a major selling point in my eyes

[benleggiero]

I agree, @jkbbwr, but the main problem I have is that I feel more stressed writing Kotlin than Swift (and even Java in this situation), because Swift forces you to handle any error thrown. In Kotlin, throwing functions are called exactly the same as non-throwing ones. It could be perfectly safe, it could throw an unchecked exception, and it could throw a checked exception. There's literally no difference at the language level. I think that's super important, because the only reason I'm using a programming language is to make a program that runs, and if literally any function call outside those I write myself might stop my program for any reason, without any way for me to know while I'm writing it, then that's a lot of stress on my shoulders. Should I just go and wrap all outside calls in a try-catch or similar handler?

[benleggiero]

Also, the philosophy of "don't add to the language what you can add to the stdlib" is that of Lisp, and I definitely don't want to write Lisp.

[Dico]

Except Lisp is also a completely different language.
As for your critique with respect to the fact that kotlin does not have checked exceptions, I think that particular "change" from Java has provided me much joy writing Kotlin. I don't use "outside calls" or library calls without knowing what they do, usually by simply looking at how they are implemented. IntelliJ makes that very easy. A lot of the time the source code is present, along with any documentation it might have.

[Dico]

And decent documentation is present for a large majority of common libraries.

[Dico]

I do agree that there is some validity to the critique - it's less safe, however, in Java you can always wrap a checked exception in an unchecked one and call it a day.

[themishkun]

@benleggiero If you program using Try or Either you enforced by the compiler to handle the error case to get the computed value back from the “error-prone” context. So it is covering your usecase completely

[benleggiero]

Yes, @themishkun, Arrow's Try pattern is good. But it's not something a first-time dev, or even an experienced dev new to Kotlin, will have the opportunity to use. As useful as Arrow is, it's not Kotlin and it's not Kotlin's stdlib. It's a third-party library that adds missing functionality to a language, because it believes that functionality is essential to using that language. This is a perfect argument to implementing such functionality in the language itself.

[jkbbwr]

As much as I like it, not everyone agrees with the purely functional style of programming you are talking about, so having it as a library is a practical consideration

[gildor]

better experience right now in Java because the compiler forces me to explicitly handle a checked exception

After 20 years of Java and experiment with checked exceptions most of devs agree that this is not a good idea and many modern Java libraries never use checked exceptions because of verbosity
What is really needed is just an IDE inspection that warns you about checked exceptions on Java code to work with API that overuse exceptions

[jkbbwr]

Unchecked exceptions with hints are great.
Result types are good but sometimes I don't care and just want to crash and die.

[gildor]

.getOrThrow()

[gildor]

or even in the future result!!

[benleggiero]

Of course, @gildor, I don't want exceptions at all. I don't want anything that could crash a program. That's one reason I like Swift's way of doing it; Errors are thrown and caught and must be handled, but they can't crash the program. Unchecked exceptions can, but Errors can't; they're more like a shortcutting second return.

I wanted to bring that peace-of-mind to Kotlin

[gildor]

IMO (and not only my) errors for branching is a bad practice. I would avoid it even if compiler force user of this API check them