Against enforce()

[Andrei Alexandrescu]

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