DIP(?) Warning to facilitate porting to other archs

[Meta via Digitalmars-d]

On Saturday, 3 May 2014 at 01:17:36 UTC, Jonathan M Davis via 
Digitalmars-d wrote:
> The problem that some of what gets warned about is _not_ 
> actually a problem.
> If it always were, it would be an error. So, unless you have 
> control over
> exactly what gets warned about and have the ability to disable 
> the warning
> in circumstances where it's wrong, it makes no sense to have 
> the warnings,
> because you're forced to treat them as errors and always "fix" 
> them, even if
> the fix is unnecessary. If the compiler provides that kind of 
> control, then
> fine, it can have warnings, but dmd doesn't and won't, because 
> Walter doesn't
> want it to have a vast assortment of flags to control anything 
> (warnings
> included). That being the case, it makes no sense to put the 
> warnings in the
> compiler. With a lint tool however, you can configure it 
> however you want
> (especially because there isn't necessarily one, official tool, 
> making it
> possible to have a lint tool that does exactly what you want 
> for your
> project). It's not tied to what the language itself requires, 
> making it much
> more sane as a tool for giving warnings. The compiler tends to 
> have to do
> what fits _everyone's_ use case, and that just doesn't work for 
> warnings.
>
> Putting warnings in the compiler always seems to result in 
> forcing people to
> change their code to make the compiler shut up about something 
> that is
> perfectly fine.
>
> - Jonathan M Davis

I'm not arguing for warnings in the compiler. If we agree that a 
linter is a good thing that everyone should use, then we should 
make it as easy as possible to use it - including having it on by 
default. It's fine if it's customizable, disable-able, etc. Then 
the users that want to tweak its behaviour or go without can do 
so.

As for what "having it on by default" means, that's up for 
debate. Currently, only the determined can use, for example, 
DScanner, as they have to clone the Github repo, compile it, and 
then set it up to use with their editor of choice. DScanner 
hasn't become a de-facto standard yet, or "officially blessed", 
of course, but as soon as that happens, rapid action needs to be 
taken to ensure that it is as painless as possible to use and 
enabled by default, preferably transparent to the casual or 
uninformed user.