On 07/17/2010 12:07 AM, Walter Bright wrote:
But of course, that's probably more work to do in the compiler.
Yes, but it's not hard. For me, the issue is making things for the user
more complicated. D is already a very large language, and adding more
and more stuff like this makes it larger, buggier, and less
approachable. For example, nothing stands out to say what "unittest
assert" does vs "assert". I'd have to continuously recheck the manual.
One thing I like about the current unittest setup is how utterly trivial
it is to use effectively.
The way I understand what you say means that assert should have uniform
semantics, whether used inside a unittest or not. Selective behavior
would be one of those RTFM things.
Is it really a good idea to have so much customizable behavior wedded
into the grammar, whereas it can be achieved using existing D constructs
(albeit with a little more typing)? I think the default behavior should
be the simplest, "git 'er done" that covers 90% of the usage needs. The
other 10% can be done with conventional D constructs.
I agree, and to me the natural consequent is - assert throws, period.
Andrei
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
