On 03/16/2011 08:53 PM, bearophile wrote:
Andrei:
Yum, love the enforce.
You are silly :-)
So perhaps the language could be improved as enforce does not break purity.
Currently enforce() uses a lazy argument. A lazy argument is a delegate, and
generally such delegate can't be pure, because the expressions you give to
enforce() usually refer to variables in the scope where you call enforce(). So
what kind of language improvements are you thinking about?
I haven't thought through it. Clearly this is a false positive, a
restriction that should be at best removed.
This is an example:
http://d.puremagic.com/issues/show_bug.cgi?id=5746
- It kills inlining (with the current DMD, and I don't think this problem will
be fixed soon);
Not a problem of enforce.
In my opinion it's not wise use widely in the standard library
something that requires an optimization that the DMD compiler is not
going to have soon, and that makes the code significantly slower. In
some cases this almost forces me to keep a patched version of Phobos,
or to add more nearly duplicated functions to my dlibs2.
No need to blow out of proportion everything that serves a point. There
are only few places in which use of enforce (or checking in general)
slows things down. We have decided to assuage that by avoiding duplicate
checks and by sometimes leaving it to the user to check (e.g. by using
assert). This is a good approach because it starts from conservative and
thoroughly checked.
enforce helps such idioms, does not prevent them. From the docs:
===============
T enforce(T)(T value, lazy Throwable ex);
If value is nonzero, returns it. Otherwise, throws ex.
===============
Then why is iota() using a nude enforce() instead of the enforce()
with a more meaningful exception like WrongArgumentException?
Because I don't condone defining large exception hierarchies. It's most
important to throw an exception. Then it's okay to refine exception
types, but that's not an issue that is the charter of enforce or that
enforce prevents.
I have
seen the nude enforce used in other parts of Phobos. So maybe
enforce() makes even the standard library writers lazy.
It makes the standard library writers productive.
enforce's specification specifies it throws. It would therefore be
difficult for it to not throw. This complaint is non sequitur.<
I know, and I agree in some situations you want an assert (to test
arguments coming from "outside"), so in some situations an enforce is
acceptable. The problem is that currently enforce is used as a patch
for a DMD/Phobos problem that I hope will be fixed in a short time,
see below.
Hoping less and doing more would be great.
I see enforce() just as a temporary workaround for a problem of
Phobos (that it's compiled in release mode, so its asserts are
vanished) that risks to become a permanent part of Phobos.<<
enforce is a simple abstraction of the idiom "if (!condition) throw
new Exception(args)". If that idiom were rare, then occurrences of
enforce would be rare and therefore there would be little need to
have enforce at all.< There may be some confusion somewhere.
enforce is not supposed to be a sort of assert. It is a different
tool with a different charter. Use assert for assertions.<
Right. But saying just that is not enough. You have to add that such
"if (!condition) throw new Exception(args)" idiom is common in Phobos
because Phobos is present only in release mode. If the zip
distribution of DMD contains two Phobos and dmd becomes able to use
the right one according to the compilation switches, then I think
that "if (!condition) throw new Exception(args)" will become more
rare, and the enforce() too will be less commonly needed.
I think you are terribly confused about the relative roles of assert and
enforce.
Andrei
