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