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?

Bye,
bearophile

On Tuesday, 25 February 2014 at 11:22:23 UTC, bearophile wrote:
> Andrei Alexandrescu:
>
>> http://www.reddit.com/r/programming/comments/1yts5n/facebook_open_sources_flint_a_c_linter_written_in/
>
> An interesting comment from Reddit:
>
> klusark>I've been trying to build this for the past hour. It requires folly. folly requires some "double-conversion" library, but you can't use the default version, you have to build it with scripts from folly's source. After I finally get folly to get past configure stage I get some random python error in one of the build scripts. I just gave up at this point. I'm sure I could get it working, but the time isn't worth it.<
>
> Bye,
> bearophile

It's kind of strange (to say the least) that a D project depends on folly and gtest - the C++ libraries. I understand that flint is not purely a D project. It also builds the C++ binary and library which depends on this stuff.

But I find it important to separate the 2. And the D version should be made as easy to setup as possible. That is - no friggin autotools, makefiles and folly/boost/gtest dependencies.

I honestly think that this stuff stands in the way of the D's adoption big time. And this flint project should really be separated into C++ and D part. With D part using unittests, phobos and dub. So using it would be as simple as "dub build" and "dub test".

The difference would be even more noticeable with a neighbor C++ project requiring all that autotools nonsense.

Being a C++ developer for a decade now, personally, I can handle the D adoption curve since in its current state it's not worse than C++'s anyway. But every time I feel really awkward recommending D to someone else. Since I know they will encounter many problems which require arcane (to newcomer's mind) knowledge.

Maybe another valuable example would be a "go fix" alternative. After every release I hear the voices "It broke every line of my code", "This release is a behemoth", "D was never and will never be stable", etc. And I really think that if it could be handled by "dub fix" - nobody would ever complain.

At DConf 2013 Andrei told to that question something like - "What do you actually want? A bash script in the error message to fix that for a whole project? Well, I guess this could be done."

So, to summarize, I guess my point is, that today's tools work so smooth and with such low entering cost, that an old-dog-C++-programmer considers it magic and doesn't really value it accordingly. And since the D crowd is mostly the old-dog-C++-programmers crowd - this aspect is really "underlooked". But the (sad or great or mere) fact is that today's students are not old-dog-C++-programmers and they have really hard time using D today. So hard, that they would actually rather use Python or Go (oh, my) or Haskell (sic!) instead of D in their work.

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?
>
> Bye,
> bearophile

Disadvantages:
1) need to distribute extra tool
2) need to keep it in sync with language

Advantages:
1) can't affect compilation semantics (__traits(compiles) + dmd -w)
2) allows defining project-specific rule set
3) becomes possible to define exceptions from general rules without affecting language
4) makes it possible to add lot of different checks without endless arguments about their applicability for all programs

On 24 February 2014 21:06, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> This is a first on so many levels.
>
> https://news.ycombinator.com/item?id=7293396
>
> http://www.reddit.com/r/programming/comments/1yts5n/facebook_open_sources_flint_a_c_linter_written_in/
>
>
> Andrei


Awesome!

I'd like to point out a cool fact: with D, we can do a number of lint like things in the language itself, especially if we extend rtinfo (I wrote about this a little while ago and might do a pull request soon)

checkBlacklistedIdentifiers -- would require modifying the header but we could @disable them

checkOSSIncludes - scan for imports, would be easier with rtinfo for modules though! but worst case i'm pretty sure we could do this as a runtime unit test with moduleinfo

Eliminate common mistakes, checkImplicitCast - a UDA + RTInfo + compile time reflection means this is checked by D


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.

"Dicebot"  wrote in message news:rkgevwccvxaynrbbixfu@forum.dlang.org... 

> Full stop. 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.

Exactly.

This sort of thing would make an excellent compiler plugin...

Am 25.02.2014 13:48, schrieb Dicebot:
> On Tuesday, 25 February 2014 at 11:20:37 UTC, bearophile wrote:
>> Currently the D compiler catches several bugs that are caught only by
>> C lints. Clang shows that you can add lot of lint-like tests to the
>> compiler. I'd like some more tests in the D compiler.
>
> Full stop. 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.

Yeah, it worked really great for C.

Developers created C compilers in other systems and never ported lint
as part of the process.

End result being a portable macro assembler, as safe as, writing in pure assembly.

--
Paulo

You don't need to port lints to use them.

Paulo Pinto:

> End result being a portable macro assembler, as safe as, writing in pure assembly.

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.

Bye,
bearophile

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.