Discussion Thread: DIP 1032--Function pointers and Delegate Parameters...--Community Review Round 1

[H. S. Teoh]

On Tue, Jul 28, 2020 at 03:30:22PM -0700, Walter Bright via Digitalmars-d wrote:
> On 4/10/2020 3:27 AM, Dennis wrote:
[...]
> > - the alternative proposal says: let `sink` *remove* attributes from
> > toString if necessary. If I call toString with a sink that does
> > printf, toString will lose the pure and @safe for that specific
> > call. If I call toString with a sink that appends to an array, it
> > will lose the @nogc for that call.
> 
> This makes the attributes added to toString ineffectual. Worse, they
> would be silently removed under your proposal. The toString's caller
> would think they are calling a pure function, may rely on it being
> pure, but the pure got silently removed.
[...]

This is a misunderstanding of what was proposed.  What was proposed is
that the compiler will treat such a call as if it were no longer pure
(@safe, nothrow, etc.). I.e., if the caller was marked pure, this would
trigger a compile error that it cannot call an impure function.  If the
caller was impure to begin with, then it doesn't matter anyway.

We are not proposing that the compiler will continue to pretend that the
function is pure in spite of having secretly removed attributes from it.
What we are proposing is that passing an impure delegate to the function
breaks its purity, so such a call is treated as if it were impure. If
the caller was expecting purity (it was marked pure), this will result
in a compile error. But pure continues to apply inside the function body
(except for the call to the delegate).  Passing a pure delegate to the
function does not break purity and therefore can be treated as a call to
a pure function (i.e., pure code is allowed to call the function as long
as the delegate is also pure).

IOW, the callee adapts itself to the attributes of the passed delegate,
rather than the other way round.  The other case, which is what this DIP
proposes, is of limited usefulness; all it does is to save some typing
in the function signature, and not much else.  If we wanted the function
to be callable both from pure and impure code (with impure delegates)
under this DIP, we would have to write two copies of the function that
are identical except in attributes. This is redundant and not useful.

What we propose -- that the function adapts itself to the attributes of
the passed delegate -- makes it possible to reuse the same function for
both pure and impure callers and avoid this code duplication, and at the
same time without breaking any guarantees conferred by the attributes.
In essence, it's the analogue of inout for pure, nothrow, @safe, etc..


T

-- 
It's amazing how careful choice of punctuation can leave you hanging: