On Friday, 29 January 2016 at 08:01:54 UTC, Ali Çehreli wrote:
Why didn't you say hi? :)


There was no chat box!

I'm pretty uncomfortable with the whole video and audio thing. I think I sound terrible and look just as bad. I prefer reading and writing.


I think we were seeing just two connections: Luís and us.

Yeah, I only saw the two boxes and myself, and I turned my camera + mic off.

Is there a reason why only auto functions have attribute inference? Why not infer all attributes unless they are overridden by explicit attributes?

The big reason is that for non-template functions, the body isn't necessarily there and it affects mangling.

So if you tried to do the whole .di thing and wrote:

void foo() { ... } // implicitly @safe implementation

and accessed it via

void foo(); // not marked, but no body so cannot be inferred...


You'd get linker errors because the bodyless one now has a different mangled name from being unable to infer.


This can also be relevant with inheritance:


class Base {
   void foo() { a+b; } // implicitly @safe
}

class Derived : Base {
   void foo() { *(cast(void*) 0) = 0; } // totally @system
}


What happens then? Is Derived.foo an error because it cannot override the implicitly @safe interface of Base.foo?

I think: yes, that's exactly what should happen.


But, what if you import an interface file again:

class Base {
   void foo();
}


Can we still make it an error? Eh, not reliably. And then the danger is: here, Base.foo *appears* to be @system, so the compiler will let you override it.

But in the file that uses it, with the full definition, the compiler inferred it to be @safe.


@safe useMyClass(Base base) {
   base.foo(); // allowed, it thinks foo is @safe
}



then the other module, compiled separately via bodyless interface, does:


useMyClass(new Derived());


...and it compiles because Derived *it believes* implements the Base interface correctly.... but now the @safe guarantee was just blown wide open.



With templates, the body must be present at *all* uses, even if compiled separately, so it doesn't fall victim to this, but other functions do bring a few worries.


(though, on the other hand, using a .di file, you could always just lie about the attributes anyway and the compiler trusts you... so maybe we aren't in that great of a position to begin with and this shouldn't be a blocker....)

Reply via email to