Can someone please give me a good use case for `in...

# codingconventions

[therealbluepandabear]

Can someone please give me a good use case for internal? Really confused as to when I'd ever need to use this, especially since most of my projects are just one module.

[Fleshgrinder]

It's useful in libraries to keep symbols limited in their visibility to that library, but only to target Kotlin consumers since Java won't know anything about it (unless you combine it with @JvmSynthetic and hide it that way).

It has no use if you only create applications.

[Joffrey]

It has no use if you only create applications

Just a detail, but this is only true for single-module applications. If your application is a multi-module project, some modules may behave like libraries and benefit from internal too

[christophsturm]

another use case: making internal data available to unit tests.

[Fleshgrinder]

I still hope that we'll get package protected at some point for this (with additional module scope behavior).

[LeoColman]

@Fleshgrinder Can you show me some use cases for package private? I never had the urge to use them in Kotlin, but I do see people missing it a lot

[Fleshgrinder]

The testing case above is a good one. You want to make something accessible to your test class, but not to the entire module. I don't have an real-world example for you from the top of my head, but I ran into it a couple of times already.
That said, I think that friend classes is generally a better solution for this rather than package protected. But, with wildcard support.

class Foo {
    friend com.example.bar.*
    friend org.example.FooBar
}

[LeoColman]

I liked that keyword. What would it make? A class only accessible by a specific package/class?

[LeoColman]

I could then do

package my.pkg

class Foo {
    friend my.pkg.FooTest

    private fun myPrivateMethod() {}  // Accessible in FooTest?
      
}

[Fleshgrinder]

Exactly 🙂 https://en.wikipedia.org/wiki/Friend_class

[christophsturm]

Yes package protected would be even better for unit testing.