Am 25.02.2014 16:49, schrieb Dicebot:
> On Tuesday, 25 February 2014 at 15:43:30 UTC, bearophile wrote:
>> I'd even like warnings active on default in D, plus a compiler switch
>> to disable them. Lot of people in D.learn don't even activate warnings.
>
> Those warning that _can_ be activated by default, should be just turned
> into errors. Same crap as with C.

There I agree.

Actually a good approach the Go guys have, everything that can be a warning, is an error.

Dicebot:

> Those warning that _can_ be activated by default, should be just turned into errors. Same crap as with C.

Programming is not a black/white thing (http://en.wiktionary.org/wiki/Manichaean#Adjective ) :-)

Bye,
bearophile

On Tuesday, 25 February 2014 at 16:07:34 UTC, bearophile wrote:
> Programming is not a black/white thing (http://en.wiktionary.org/wiki/Manichaean#Adjective ) :-)

Which is exactly why you can't put this stuff into compiler - providing comparable amount of cofigurability as expected from dedicated lint tool will considerably complicate it. And sticking no non-configurable defaults is akin to -Werror in C: either you enable it and pollute your code with hacks to prevent triggerring of warnings in rare legit cases or just ignore for most time.

On Tuesday, 25 February 2014 at 12:58:03 UTC, bearophile wrote:
> Dicebot:
>
>> It should be other way around - remove all such arguable warnings from compiler to dedicated lint tool and never add any single one to compiler.
>
> What are the advantages and disadvantages of doing as you say?
>

http://en.wikipedia.org/wiki/Separation_of_concerns

On 2/25/14, 3:07 PM, deadalnix wrote:
> On Tuesday, 25 February 2014 at 12:58:03 UTC, bearophile wrote:
>> Dicebot:
>>
>>> It should be other way around - remove all such arguable warnings
>>> from compiler to dedicated lint tool and never add any single one to
>>> compiler.
>>
>> What are the advantages and disadvantages of doing as you say?
>>
>
> http://en.wikipedia.org/wiki/Separation_of_concerns

Yes, it can be a separate module in the source code of the compiler.

The compiler is the only one that has most information to provide lint errors.

If the lint has tests, if you change the compiler you immediately can tell if the linter stopped working correctly or needs an update.

If it's separated then it's always the turtle chasing the rabbit.

On Tuesday, 25 February 2014 at 18:34:49 UTC, Ary Borenszweig wrote:
> Yes, it can be a separate module in the source code of the compiler.
>
> The compiler is the only one that has most information to provide lint errors.
>
> If the lint has tests, if you change the compiler you immediately can tell if the linter stopped working correctly or needs an update.
>
> If it's separated then it's always the turtle chasing the rabbit.

Ideally, you'd provide semantic analysis as a library, and use it in the compiler AND in the linter.

That is even more separation of concerns, and that works well.

On 2/25/2014 10:34 AM, Ary Borenszweig wrote:
> If it's separated then it's always the turtle chasing the rabbit.

I like Adam's idea of improving reflection so such linters could be written as D code and compiled in.

On 2/25/2014 6:53 AM, Adam D. Ruppe wrote:
> well a lot of these are obviated by D itself too...  but checking reflection,
> especially with a project-wide rtinfo extension so you don't have to static
> assert in every module, gives D the potential to lint itself with some
> user-defined semantics.

This is a most interesting idea. Please pursue.

Am 25.02.2014 20:36, schrieb Walter Bright:
> On 2/25/2014 10:34 AM, Ary Borenszweig wrote:
>> If it's separated then it's always the turtle chasing the rabbit.
>
> I like Adam's idea of improving reflection so such linters could be
> written as D code and compiled in.

Yes, other languages are starting to offer such capabilities via compiler plugins.

Could be something interesting.

--
Paulo

On 2/25/2014 12:54 PM, Paulo Pinto wrote:
> Am 25.02.2014 20:36, schrieb Walter Bright:
>> On 2/25/2014 10:34 AM, Ary Borenszweig wrote:
>>> If it's separated then it's always the turtle chasing the rabbit.
>>
>> I like Adam's idea of improving reflection so such linters could be
>> written as D code and compiled in.
>
> Yes, other languages are starting to offer such capabilities via compiler plugins.
>
> Could be something interesting.

I don't mean as a compiler plugin.