On 2011-02-01 10:34:26 -0500, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> said:
On 2/1/11 9:21 AM, Don wrote:
Jonathan M Davis wrote:
Do you really find
assertPred!"=="(min(5, 7), 5);
to be all that harder to understand than
assert(min(5, 7) == 5);
I do. *Much* harder. Factor of two, at least.
In absolute terms, not so much, because it was the original assert is
very easy to understand. But the relative factor matters enormously.
Much as comparing:
a.add(b);
a += b;
And I think this is a very important issue.
>I don't see how these functions could be anything but an improvement.
> But even if they get into Phobos, you obviously don't have to use them.
This is not true. Including them in Phobos gives a legitimacy to that
style of programming. It's a role model.
Including stuff like this could give D a reputation for lack of
readability. My belief is that right now, the #1 risk for Phobos is that
it becomes too clever and inaccessible.
IMHO, something simple which has any appearance of being complicated,
needs a VERY strong justification.
Does this count as a vote against the submission?
To me this is a compelling argument against. That and the fact that it
can't really mimic the true behaviour of assert in some situation.
assertPred won't work correctly for 'in' contracts with inheritance,
where the compiler generate the assertion code differently.
In my view, the correct way to improve assertion error messages is to
improve how the compiler handle assertions (it should output messages
like it does for static asserts).
assertPred might be fine as a stopgap solution, but personally I'd not
make it part of the public API. We can't tell people to use assert()
everywhere and then tell them they should use assertPred!op() if they
want a useful error message except for 'in' contracts of virtual
functions; that'd just be too confusing.
--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/
