DIP1028 - Rationale for accepting as is

Q. Schroll qs.il.paperinik at gmail.com
Thu May 28 00:57:15 UTC 2020


On Friday, 22 May 2020 at 18:14:12 UTC, H. S. Teoh wrote:
> Then myFunc would become callable from @safe code, provided the 
> passed-in argument is also @safe.
>
> The crucial point here is that while compiling myFunc, the 
> compiler doesn't (need to) know the @safe-ty of `cb`, it can 
> just treat it as an opaque object that it assumes the safety 
> of, while it verifies the rest of the function body.
>
> This is parallel to C functions being of unverifiable safety, 
> so if extern(C) functions were somehow marked and treated as 
> opaque objects of unknown safety, then the compiler can still 
> verify the rest of the code and produce a certificate of safety 
> (modulo the C APIs used).
>
> If we had a way of expressing conditional safety, it could be a 
> way to salvage @safe from this current situation.

I had this thought a million times, tried to explain it at two 
DConfs but no-one (as it appeared to me) got the point.

The main difference is, the function calling `myFunc` "knows" 
whether the delegate/function pointer it used as an argument is 
@safe or not. It's perfectly decidable.

Personally, I'd even go that far and say, that's how all the 
function attributes (also pure, nothrow, @nogc) are intended to 
work.


More information about the Digitalmars-d-announce mailing list