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