https://kotlinlang.org
Join Slack
Oh wow - the survey is very difficult. It’s VERY challenging choosing only 3. I’m having to categori...
# announcements
s
Oh wow - the survey is very difficult. It’s VERY challenging choosing only 3. I’m having to categorize things and rate them based on how much they would improve my quality of life.
b
Tell me about it! Took me 10mins of thinking to pick 😄
s
Reading all the descriptions, I was getting so excited. I felt like I was at a candy store. I was a little disappointed by the package-private visibility. Their follow-up questions show that they are only considering it for internal module use. Part of why I want package private visibility is so that I can expose an internal API between multiple library artifacts, however it appears that isn’t a use-case they are considering.
b
To me personally it was the one I was least interested in. Can't wait for union types. Odly enough, they somehow completely ignored their use-cases for js external declarations 😕
s
Can’t wait for union types
I wish I had voted for union types. Based on the wording of the title, it seemed specific to exceptions. I didn’t realize it was a general feature until I went back through and read each feature again
b
Yeah, they focused on exceptions but there was also an example of function returning union types
s
To me personally it was the one I was least interested in
How often do you write libraries?
b
Fairly often, but i'm fine with internal
➕ 5
s
I find it frustrating and ugly when I have to expose an internal API publicly so that it can be used with external artifacts.
d
You can work around that fairly easily with a custom 
@MyLibraryInternalApi
which requries opt-in
Similar to how kotlinx.coroutines does it
s
Good call out but still ugly.
I think I’m most excited for multiple visibilities on properties
r
I find it frustrating and ugly when I have to expose an internal API publicly so that it can be used with external artifacts.
Can you elaborate on the distinction between "expose publicly" and "use externally"? They sound like the same thing to me.
s
In Kotlin, in order to use something between libraries, it has to be in the public name space
r
Yes, because "using something between libraries" is, as far as I understand it, exactly what public means.
💯 3
s
It’s not really different libraries though. It’s different artifacts of one library.
Broken up so that you only take what you need.
Being able to curate your public API so that only exactly what needs to be exposed publicly is no longer possible then.
However - you can do exactly that with package private visibility in Java.
i
It's not a promising practice even in Java - to share a package between multiple artifacts. For example, Java module system prohibits such configurations when multiple modules have the same package, so called split package situation.
☝️ 1
e
It’s VERY challenging choosing only 3
It took a lot of thinking to decide on the 3 that I voted for, although I suppose that was the point. What I ended up doing was voting for the 3 that I felt had the most functional impact right now, as opposed to something that would make life easier. I'm hoping that the latter features will get added as well, just farther in the future.
g
Good call out but still ugly.
Looks much more clear and very explicit comparing to package private, where you cannot distinguish use case of package private for current module, or between modules. I think in general access to the same package from another module using package name is more a hack and implementation detail and always was And as Ilya mention it’s not working anymore even in Java with module system (you have opt in explicitly) and OptIn annotation looks as better and more flexib solution than opt in on level of runtime like in Java
➕ 1
s
alright - I think you guys have convinced me. I kind of wish I hadn’t voted for it now.
2 Views
Open in Slack
PreviousNext
Powered by

kotlinlang

A modern programming language that makes developers happier.

Powered by