playing around with D

Bill Baxter dnewsgroup at billbaxter.com
Wed Mar 7 09:08:45 PST 2007


Don Clugston wrote:
> Frits van Bommel wrote:
>> Don Clugston wrote:
>>>
>>> Given how common static assert(0) is, I wonder if something could be 
>>> done to improve the error message quality in the
>>> "static assert(0, "xxx")" case?
>>>
>>> file.d(58): static assert  (0) is false, "xxx"
>>>
>>> Maybe drop out the "(0) is false" bit, since it doesn't seem to add 
>>> much value, changing it to something like:
>>>
>>> file.d(58): static assert, "xxx"
>>>
>>> Or even drop the 'static assert' bit entirely, and just display "xxx".
>>
>> I don't think dropping the 'static assert' bit is a good idea (at 
>> least, without replacing it with something of similar meaning). I 
>> think it's a good thing that static asserts are clearly distinct from 
>> compiler-generated errors. The exact wording could be different but it 
>> should be clear that this is an error because the author of the code 
>> explicitly _made_ it one, not because of any inherent language rule 
>> (other than the one on static assert, obviously).
> 
> Why is it important to distinguish between an error that's detected in a 
> library, compared to one that is detected by the compiler? I would think 
> that a library writer would have the decency to explain in the text of 
> the error, that the error occurred in the library.
> 
> somefile.d(25): "SnazzySQL: Syntax error in SQL statement 'SELET * FROM 
> CUSTOMERS'"
> 
> (You could be correct, it's just not obvious to me).

There may be other reasons, but often IDEs will take you to lines where 
errors were generated, sorting those that are errors ahead of lines that 
were warnings or informational or what have you.

For that to work though, prefixes need to be consistent.  An IDE won't 
know if "SnazzySQL" is an error a warning or what.  So from my POV at 
least static asserts should be prefixed with *something* fixed, but I 
don't care so much if it's just "somefile.d(25): Error" or 
"somefile.d(25): static assert.

If the latter then an IDE could have a rule that prioritizes static 
asserts over other errors.  Don't know how useful that would be though. 
  Seems common to only distinguish 3 categories -- Error (this won't 
compile),  Warning (this might cause trouble at runtime), Information 
("hey I'm going to link with phobos.lib, ok?")

--bb



More information about the Digitalmars-d mailing list