At least one language ( is it D? I forgot ) allows you to override visibility modifiers with a command line switch. This is useful when compiling unit tests, as it avoids things so commonly found in other languages:
public Foo foo;
void setTheBar(int value);
etc. It can also dramatically lessen the need for convoluted dependency injection techniques. C++ has the notion of a “friend class” that can ignore its visibility constraints.
All this has always seemed like a lot of sense to me. Visibility modifiers in the Java world provide two fairly separate things:
- Ability to craft a well designed API so tools like IDEs and compilers can ensure you only use intended entry points.
- Ability to sandbox code
The Java world has a standardised build layout and tools that automatically understand the difference between unit tests and main program code depending on where they are in the tree. It'd be nice if the Kotlin toolchain used these conventions to compile the main code twice: once in which everything is public for the unit tests to use, and again for the real shipping product. This would make the change transparent to API and sandboxing users, whilst avoiding the need to poke holes in visibility for testing.
For bonus points kotlinc could generate the two libraries in parallel, with a “last second” bytecode rewriting pass for the second jar making everything public.
I don’t know how easy this would be to implement, but it’d be a cool feature for possibly not much work and would solve a practical problem I’ve encountered many times in real Java codebases.