Improving assert-printing in DMD

Jonathan M Davis via Digitalmars-d digitalmars-d at puremagic.com
Fri Oct 2 02:46:51 PDT 2015


On Friday, 2 October 2015 at 09:32:23 UTC, Atila Neves wrote:
> On Thursday, 1 October 2015 at 17:19:39 UTC, Per Nordlöw wrote:
>> On Thursday, 1 October 2015 at 14:37:55 UTC, Andrei 
>> Alexandrescu wrote:
>>> Whoever wants to work on better assert expression printing: 
>>> make sure you specify which grammar constructs are supported, 
>>> and how the parts involved are printed. Expressing semantics 
>>> via lowering would be great. Write a DIP, discuss, implement. 
>>> I'll have your six.
>>>
>>>
>>> Andrei
>>
>> A first version:
>>
>> http://wiki.dlang.org/DIP83
>
> I like the idea, I just have a practical question on 
> std.experimental.testing: should it go ahead as-is? Should the 
> custom assertions be removed and the rest kept? Should they go 
> in as-is and then deleted when/if this DIP is implemented?

If we're going to be improving the built-in assertions, then I 
don't think that it makes sense to add custom assertions to 
Phobos, and I definitely don't like the idea of adding them with 
the idea that we'll just be deprecating them later. If it turns 
out that that isn't going work (Walter rejected it the last time 
it was done, but maybe that will go differently this time - 
particularly since Andrei is very much in favor of it), then we 
can add the custom assertions later.

Personally, I think that the parts of this module which really 
matter are the unittest names (though I still wish that we'd just 
put that in the language itself - particularly since each 
unittest block already has a corresponding function that's named 
after where it is and it really shouldn't be a big deal to just 
allow the user to provide a name to use instead) and the parts 
about parallelizing unittest blocks. Even if we don't end up with 
improvements to the built-in assertions, the custom assertions 
are just gravy that makes it so that you're less like to have to 
go change your unit tests to print more info when they fail. So, 
I don't think that it's a big deal if they get delayed while we 
wait and see if we can get the built-in assertions improved, and 
if the built-in assertions do get improved, then we'll never need 
the custom ones anyway.

- Jonathan M Davis


More information about the Digitalmars-d mailing list