"with" should be deprecated with extreme prejudice

[Don]

Nick Sabalausky wrote:
> "Nick Sabalausky" <a at a.a> wrote in message 
> news:guscm2$2jff$1 at digitalmars.com...
>> "Don" <nospam at nospam.com> wrote in message 
>> news:gurkuo$17nv$1 at digitalmars.com...
>>> Nick Sabalausky wrote:
>>>> "Don" <nospam at nospam.com> wrote in message 
>>>> news:gur1ec$18a$1 at digitalmars.com...
>>>>> If warnings exist, libraries must not do anything that creates a 
>>>>> warning. They are NOT optional.
>>>> That's only true if a compiler (such as DMD) is only capable of treating 
>>>> warnings as errors.
>>> No. Users complain if library code generates warnings. Because a user 
>>> cannot make their code warning-free if the libraries they use are 
>>> generating warnings.
>> They can if they use a prebuilt version of the library, a lib/a/dll.
> 
> Warnings are optional built-in lint tools (kinda like how we already have a 
> built-in doc tool, built-in code generation tool (ie, mixins), built-in 
> profiling/code-coverage, etc). And it's pretty difficult to claim that lint 
> tools are bad.

If they are standardised, they _are_ bad, because they become mandatory 
for libraries. If they're not standardised, no problem, it's just a 
third-party tool which you particular users find helpful in eliminating 
bugs; and demanding that a library support your third-party tool is 
unreasonable.

Warnings can be categorised based on "probability that they indicate a 
bug", with a range from:
(1) it almost always indicates a bug --> in this case, it should be an 
error.
(2) it hardly ever indicates a bug --> in this case, it's useless at 
best, but in practice it's harmful.

If there's anything in between, it indicates a weakness in that part of 
the language design.
DMD's warnings are now extremely close to (1), I hope they can become 
errors soon. (Eg, leaving off a return statement in a function which 
doesn't contain asm statements is almost guaranteed to be a bug).