why is it applied to tests?

# language-evolution

[Mikhail]

why is it applied to tests?

[Joffrey]

Why not, though?

[Mikhail]

I mean, any public declarations in test module are already encapsulated, simply because they are in tests

[Joffrey]

Then it doesn't hurt to mark those internal

[Mikhail]

Yeah, surely

[Mikhail]

but... can't the Kotlin compiler consider any public declaration in tests as internal ?

I think I have an idea for a compiler plugin

[Mikhail]

Actually, I saw someone marking test classes as internal

[Joffrey]

IMO it's easier if everything is consistent, so I don't mind the extra internal declarations in tests when necessary, as long as everything behave the same. But I can see why people would find some benefits in having this implicit internal by default for tests

[dmitriy.novozhilov]

Well, actually test modules can depend on other test modules
So I don't see any difference between main and test modules in terms of internal visibility

[Mikhail]

Oh, yeah, I hadn't thought of that

[Mikhail]

Well, is there any way to apply test module for Explicit API Kotlin compiler feature? 😁

[Mikhail]

figured it out:

...
freeCompilerArgs = listOf("...", "-Xexplicit-api=strict")
...

[Klitos Kyriacou]

Does the Kotlin compiler even know that it's compiling a test module?

[Mikhail]

Maybe the Kotlin plugin runs compilation for each module separately

[dmitriy.novozhilov]

Does the Kotlin compiler even know that it's compiling a test module?

No, it doesn't

Maybe the Kotlin plugin runs compilation for each module separately

Yes it is. There is no difference for compiler between main and test modules
The only difference on the build system side, which marks main module as friend for test one, which allows to use internal declarations from main in test