I'm a bit late to this party, but I read through the discussion and think I have something new to add.
I would vote against the proposal as written, for reasons already stated by others, but I have a suggestion. If what you're after is warnings that can be turned off in code or via compiler flags, would annotations be more palatable approach than imports for the code part? It could be consistent with how you can turn off an unchecked warning with @unchecked.
I think the Scala value proposition could be enhanced by *useful* warnings. I wouldn't mind being warned that I'm calling apply on a LinearSeq, for example. Even though I know better, I think I've probably done that quite a bit, and I'd usually rather not. I might like being warned I'm using reflection via a structural type, in case I wasn't aware of it. These are lint-like warnings, though, so I'm not sure to what extent the Scala compiler should be in the business of providing these, versus having them provided through compiler plugins.
My gut feeling is the compiler should probably stay focused on compiling, and an ecosystem of compiler plugins could add extra warnings and error messages. Users could enable extra checks that matter to them by including compiler plugins of choice, then turn off individual warnings by changing the offending code, or annotating it with an annotation that signals to readers what is being done there -- @ReflectionBeingUsed or @LinearTime, etc. -- annotations defined by the compiler plugins. A compiler plugin could also kill the build if macros were found to be used. If that's important to me, I could insert such a plugin into our project's build.
A few warnings that you feel are very important could be built into the compiler, like the unchecked warning is. But I suspect static analysis tools and compiler plugins might be a better place to take care of most of these kinds of issues.
On Saturday, March 17, 2012 6:37:01 PM UTC-7, Martin wrote:
On Sat, Mar 17, 2012 at 11:13 PM, Debasish Ghosh <> wrote: > What's the major force towards this ? Is it only to present a smaller > surface area to newcomers in Scala ? > Definitely not. The selected features are ones which I would prefer to be explicit about in every codebase I collaborate in. For instance, if I accidentally use a structural type I want to be warned about it, mostly because I care about performance. Or, if someone I collaborate with uses postfix operators I also want to see that upfront. And so on. So I think the flags will be valuable for most Scala codebases, with typical exceptions being DSLs.
The main feature left out are implicits. Implicits are probably misused more often than any other part of Scala, but requiring them to be put wholesale under a flag would mean we think all type-class oriented programming is a special case, and that's absurd. So we'd need a crisp definition what constitutes a problematic implicit (implicit conversions, maybe?) I could not convince myself of a good criterion so far, so I left them out.