Expanding the horizons of D purity

[H. S. Teoh]

On Sun, Nov 03, 2013 at 12:00:07AM +0400, Denis Shelomovskij wrote:
> 01.11.2013 21:12, H. S. Teoh пишет:
> >On Fri, Nov 01, 2013 at 08:59:29PM +0400, Denis Shelomovskij wrote:
> >>01.11.2013 0:05, H. S. Teoh пишет:
> >[...]
> >>>So, in a nutshell, my proposal is:
> >>>
> >>>- Functions that, besides invoking a delegate parameter, are pure,
> >>>  should be allowed to be marked as pure.
> >>>
> >>>- Template functions that, besides invoking a delegate parameter,
> >>>  perform no impure operations should be inferred as pure.
> >>>
> >>>- A function that takes a delegate parameter cannot be strongly
> >>>  pure (but can be weakly pure), unless the delegate itself is
> >>>  pure.  (Rationale: the delegate parameter potentially involves
> >>>  arbitrary references to the outside world, and thus cannot be
> >>>  strongly pure.)
> >>>
> >>>
> >>>T
> >>>
> >>
> >>The code you like to make working looks good but I'm against the
> >>language change. I'd say the issue is nested pure functions aren't
> >>allowed to access outer function variables. Filed as Issue 11412.
> >[...]
> >
> >No, that's not good enough. What if you need to pass an impure
> >delegate to toString()? Sure, std.format can be made to use only pure
> >delegates, but you can't predict other code that needs to use
> >toString. Forcing toString to take only pure delegates makes it
> >unusable with output ranges that need to perform impure operations.
> >With my proposal, toString will work with *both* pure and impure
> >delegates -- basically, the pure qualifier becomes a dependent purity
> >("purity of this function depends on the delegate parameter, body of
> >function is pure besides the invocation of the delegate").
> >
> >
> >T
> >
> 
> I'd say `@safe`, `pure`, and `nothrow` are in the same boat here and
> the solution should work for them all. Probably we will need a
> delegate attributes wildcard. Something like this:
> ---
> // a single wildcard for all:
> void f(void delegate() @attr_wildcard del) @attr_wildcard;
> ---
> or better:
> ---
> // `f` is `@safe`, it also `pure` and `nothrow` if `del` is:
> void f(void delegate() @safe pure? nothrow? del) @safe pure? nothrow?;
> ---

I agree that attribute wildcards would be the ideal solution, sorta like
inout for safe/pure/nothrow.


> Also, do you disagree with the proposal in Issue 11412 [1]?
> 
> [1] http://d.puremagic.com/issues/show_bug.cgi?id=11412
[...]

I think it's OK, it's just that it doesn't quite go far enough. My
proposal would allow us to push the envelope farther without introducing
more new syntax, but if we're OK with adding more syntax, then attribute
wildcards would be the way to go.


T

-- 
Windows 95 was a joke, and Windows 98 was the punchline.