I was wondering if there are plans for providing a way to configure the default values use by the compiler on a given module for things such as the default visibility modifier (which not everyone likes as it’s been shown on certain discussions) or default convention names for operator overloading and other things about the language (which could be very useful).
Also, maybe allowing for further configuration of the compiler could help keeping annotation usage the way it’s been for so long (without requiring them to be prefixed with ‘@’ http://blog.jetbrains.com/kotlin/2015/08/modifiers-vs-annotations/), because their meaning could be known right before the parsing stage and also things such as clashes (what’s mentioned about introducing a new ‘foo’ modifier and breaking someone’s code) could be easily solved.
So what do you guys think? It’s this even possible given the technical complexity it might involve or your philosophy about what Kotlin should/shouldn’t be?
PS: I might be asking something that’s already been discussed thoughtfully because I’m relatively new to Kotlin, so bear with me please if that’s the case.
Having the same opinion as Cedric here. And just to add, I don't think it's wise for code getting meaning from compiler settings. Suddenly code can have different meaning depending on the flags of the compiler. Code should always mean the same because that's the only way people who read your code understand what's going on.
We have no such plans. We want Kotlin to be a single language, not a family of related languages with the compiler options for selecting which language exactly you want to use.
I never expected you to throw away all the propositions at once (well, at least not all to the same trash can). So let’s see how I reply appropriately to try to explain them (or at least make them look better?, lol).
The argument about suddenly only being able to compile your sources with specific compiler settings is similar to stating that you are unable to compile a program when a file is missing (which is normally true unless that class represents an isolated alternative implementation of a part of your program or something similar), so I’m not bought by it.
-Suggesting the possibility of configuring the annotation’s meaning was just a possible solution I saw when read the point of the modifiers needing to be available right after the parsing stage in the referenced article (http://blog.jetbrains.com/kotlin/2015/08/modifiers-vs-annotations/), I never suggested it for altering any other part of the language. And even though I don’t like this suggestion (funny, even though I’m suggesting it), my intention was simply proposing a solution along the lines of the dream described in the article (I’m a fool, perhaps I should have written the suggestion as a comment on the article’s page instead?).
-So just to be totally sure about the first suggestion, are you totally against the possibility of being able to configure some of the language’s default values? Maybe being able to configure default imports for your files or add new naming conventions (without removing existing ones)? It could be similar to what you can do when using Lombok in Java (many people hates Lombok, I know, but many people loves it too), in it you are able to configure many of the default values use for the annotations—which then obviously affect the generated code—in a global manner (well, actually more flexible than that) using a configuration file.
I hope this clears well what I wrote in the first post, though I think from now on I better focus on trying to till the scale in favor of default values that conform to what I use the most disregarding any other alternative values or opinions (should I then suggest a poll functionality on this forum?).
As far as I know, out of all this list, the only possibilty that we've discussed is the possibility to specify default imports. We had a prototype design where the compilation of a module would be driven by a special "Kotlin module file", and it would be possible to specify the default imports for the module there. That design is not going to be implemented in 1.0, but it might appear some time in the future.
I’m not sure what you mean by “adding new naming conventions”. The set of operators which we allow the users to overload through naming conventions is fixed. We’re quite certain that we do not plan to allow users to redefine arbitrary operators. If you want to redefine one of the operators that can be redefined, but aren’t happy with the name that Kotlin uses for the function, you’re welcome to define an extension function with your preferred name that will map to the standard Kotlin name.
We’re also pretty sure that we aren’t going to add the possibity to configure things like the default access level for members. Making this configurable creates a huge amount of complexity and confusion which is simply not worth it.