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

[H. S. Teoh]

On Tue, Jul 28, 2020 at 06:21:44PM -0700, Walter Bright via Digitalmars-d wrote:
> On 7/28/2020 4:00 PM, H. S. Teoh wrote:
> > 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.
> 
> Thanks for the clarification.
> 
> But it still tricks the user into thinking the function is pure, since
> it says right there it is pure. Pure isn't just an attribute for the
> compiler, it's for the user as it offers a guarantee about what the
> interface to a function is.
[...]

In that case, what about extending inout to attributes besides const? I
don't know what's a good syntax for it, maybe something like
inout(pure), for lack of a better idea, to indicate conditional purity?

It's basically the same idea as inout: as far as the function body is
concerned, it's pure (resp. const); but to the caller, it could be pure
or impure (resp. immutable/mutable) depending on what was passed in. I
argue that this would be much more useful than what this DIP proposes.


T

-- 
Talk is cheap. Whining is actually free. -- Lars Wirzenius