What is the rationale behind the decision not to p...

# announcements

[thana]

What is the rationale behind the decision not to provide a "package private" visibilty? (i think even better would be something like a "friend" visibility)

[marstran]

internal is your "friend" visibility 🙂

[hho]

If you group all friends in a module, internal is exactly that.

[thana]

yeah but that way i need to split parts pf the application into multiple modules which actually make up the application only together

[hho]

yes, but that's … normal. Nobody said that every module has to be a complete application.

[thana]

true - yet it feels very clutterted to me

[oshai]

I'm also missing something like that for multi module libs

[karelpeeters]

I'm missing this too, modules are just extra hassle over packages.

[ghedeon]

I threw myself on this sword, guys! 😆
https://youtrack.jetbrains.com/issue/KT-29227

[thana]

Thank you 😄

[ghedeon]

yeah, it's slowly getting attention. Frankly speaking, I gues JB guys got hyped by Swift in this matter. Which is ironic, because my swift colleague just got overly excited over the Dart, because "man, it's so awesome, you can group/hide stuff there and in swift it's all public so it's either a long name or some hacks with enums in order to create a namespace". Bitch, please, we've been using it for years simple smile

[thana]

i think what people are always missing is, that visibility is not about security, but about hinting the users about how the library/interface/whatever is meant to be used

[oshai]

I wish there was visibility of pakcage + sub package private