Improving assert-printing in DMD

[deadalnix via Digitalmars-d]

On Friday, 2 October 2015 at 00:05:33 UTC, Timon Gehr wrote:
> On 10/02/2015 01:33 AM, Andrei Alexandrescu wrote:
>> On 10/01/2015 06:41 PM, Timon Gehr wrote:
>>> On 09/30/2015 03:10 PM, Andrei Alexandrescu wrote:
>>>>
>>>> I encourage making assert smarter seeing (a) it's already 
>>>> used
>>>> everywhere so the benefits will come for free  and (b) it's 
>>>> a built-in.
>>>> -- Andrei
>>>
>>> About (b): I'm surprised to see that you seem to have so 
>>> fundamentally
>>> changed your attitude towards magical semantics for built-ins.
>>
>> I haven't - I still think making "assert" a built-in and 
>> ascribing a
>> keyword to it was a minor mistake. But then that sail has 
>> shipped, so
>> let's make the best use of the situation. -- Andrei
>>
>
> Ok, but if assert gets special error printing capabilities that 
> are not available at the same level of convenience to e.g. 
> enforce, then this is a roughly analogous situation to having 
> e.g. B[] : const(A)[] for B : A, which cannot currently be 
> simulated in the library in a satisfactory way. Those 
> situations usually add friction. They tend to result in 
> frustration and often culminate in proposals for new, often 
> ad-hoc language features. IMHO, there ought to be a better way, 
> but I don't have a very strong opinion about this particular 
> case.

On the other hand, changing the language to provide access to 
this as library would require something macro like, and both 
Andrei and Walter seems to be really against it.

As we are on assert, 2 things :
  - Before considering adding more magic, can we get line numbers 
in stack traces ? It really seems to me like improving the 
message no stack trace is available is not focusing on impact.
  - assert already have a fair amount of magic, notably assert(0) 
change the way control flow works. Having it as an expression is 
making everything very convoluted for no reason.