[phobos] Pureness of enforce()

[Andrei Alexandrescu]

We should leave enforce() as is and defining eagerEnforce() or 
pureEnforce().

1. No backwards-incompatible change

2. enforce() continues to mimic assert()'s behavior wrt its second argument

3. I'm not sure there will more pure functions than impure out there. If 
there are more impure functions, using enforce() becomes a net pessimization

If we make the change, I see "Effective D" item #35: "Beware of 
enforce()'s inefficiency".


Andrei

On 11/12/10 4:20 AM, Lars Tandle Kyllingstad wrote:
> On Tue, 2010-11-09 at 08:48 -0800, Andrei Alexandrescu wrote:
>> On 11/9/10 8:34 AM, Don Clugston wrote:
>>> On 9 November 2010 16:15, Robert Jacques<sandford at jhu.edu>   wrote:
>>>> On Tue, 09 Nov 2010 06:21:38 -0500, Lars Tandle Kyllingstad
>>>> <lars at kyllingen.net>   wrote:
>>>>>    It is not possible to annotate
>>>>> enforce() with 'pure', however, because it takes a lazy parameter, which
>>>>> is just shorthand for a (possibly impure) delegate.
>>>
>>>> Well, long term, we need modifiers to apply to delegates. i.e. it should be
>>>> possible to declare a pure delegate.
>>>
>>> You can already do that.
>>>
>>> int delegate(int x, int y) pure @safe foo;
>>
>> Cool! Then overloading enforce on purity should be the solution.
>
>
> I am not quite satisfied with the conclusion of this discussion.  There
> are currently two big problems with enforce() taking a lazy parameter:
>
> 1. It prevents enforce() from being marked as pure, thus preventing
> major parts of Phobos from being pure, thus again preventing a lot of
> user code from being pure.
>
> 2. It prevents any function that uses enforce() from being inlined, thus
> degrading performance.  (See the "std.algorithm.sort slow as molasses"
> discussion, from July, on this list.)
>
> Solving these two issues require changes to the compiler, and I suspect
> it's not at the top of the priority list.
>
> Until that happens, can we please follow Steve's suggestion and make
> enforce() non-lazy and temporarily add a lazyEnforce() for those cases
> where the error message is actually expensive to construct?
>
> -Lars