playing around with D

[BCS]

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).

1) Never trust convention or decency to make people do something that is 
*needed*

2) compile errors are usually the fault of the lib, asserts are the 
fault of the user. Also the asserts will probably be more useful when 
trying to fix things.