@safe quiz
Walter Bright
newshound1 at digitalmars.com
Wed Dec 30 21:16:08 PST 2009
Michel Fortin wrote:
> On 2009-12-30 20:20:30 -0500, Walter Bright <newshound1 at digitalmars.com>
> said:
>
>> I think that shows the type system is working.
>
> I think it shows that the type system is too strict and easily gets in
> the way.
I think we can work to address those problems while keeping it strict.
C++ const is an example of a not strict system which offers (as a
consequence) no useful guarantees at all.
>> If a @safe function can call a not safe delegate, then the type system
>> has failed.
>
> A @safe function is only safe when given safe arguments. If a system
> function calls a safe function by giving it a garbage pointer, that safe
> function is able to corrupt anything.
That's correct.
> The same should apply for callable arguments (function pointers and
> delegates): a system function should be able to give a system delegate
> to a safe function, and that safe function should be able to call it.
> It's the caller that should be held responsible for giving an unsafe
> argument, and if the caller function is safe it shouldn't be allowed to
> pass an unsafe function as an argument.
I'll have to think about that one. I'm not sure I agree. But I'm glad
you're bringing it up, it's important. I hadn't thought about this issue
before.
> Here is a pathetic example of something that does not work currently:
>
> struct R {
> @safe int opApply(int delegate(ref int) z) {
> int i = 1;
> return z(i); // Error: safe function 'opApply' cannot call
> system delegate 'z'
> }
> }
>
> @system
> void someSystemFunction() {
> R r;
> foreach (i; r) { writeln(i); }
> }
>
> Should I have to write the opApply twice so it can work with both system
> and safe functions? I sure hope not. Even then, this does not compile
> either:
>
> @safe
> void someSafeFunction() {
> R r;
> foreach (i; r) { writeln(i); } // Error: function untitled.R.opApply
> (int delegate(ref int) z) is not callable using argument types (int
> delegate(ref int __applyArg0))
> }
There is certainly a problem here in that when the compiler creates the
delegate to send to opApply, it doesn't tag it appropriately (or at
all). These kinds of issues are to be expected with a new feature like
@safe, a couple of iterations will be necessary to straighten them out.
More information about the Digitalmars-d
mailing list