Re: An interesting consequence of safety requirements

[grauzone]

Andrei Alexandrescu wrote:
grauzone wrote:
Andrei Alexandrescu wrote:
Something just dawned on me: in safe mode, struct static member 
functions will be preferred to struct non-static member functions.

Why?

Consider:

struct List(T) {
    T payload;
    List * next;

    void prepend(List * newNode) {
        newNode.next = &this;
    }
}

This code can't make it in safe mode because it takes the address of 
this. In general, the compiler must assume that you might have 
created a List object on the stack, e.g.:

List * someFun() {
    List local;
    List * lst = new List;
    local.prepend(lst);
    return lst;
}

Now even if there is no ostensible local address taking, the code is 
in error because it has escaped the address of a local.

So prepend() cannot be compiled. The way to make it compile in safe 
mode is:


struct List(T) {
    T payload;
    List * next;

    static void prepend(List * zis, List * newNode) {
        newNode.next = zis;
    }
}

Now the code compiles and is actually safe because it is impossible 
to pass the address of a local into prepend.

Maybe I don't get it, but how to you call prepend() from safe code?

module(safe) wyda;

void main() {
    auto lst1 = new List;
    auto lst2 = new List;
    List.prepend(lst1, lst2)
}

I see... in this case, I'd say the user should be forced to allocate 
List on the heap by making List a class. Of course, you could say that 
it should be useable in other, unsafe, contexts too (maybe you want to 
construct a list of the stack); but then you could use... InSitu!(T), or 
what was it called?

Also, does anybody really care about SafeD, or would it be better if 
we had some sort of valgrind for D? Maybe this is one of those 
features which first sounded nice, but then it turned out it's better 
to drop them.

I'm not sure, but clearly soundness is an important concern in 
contemporary languages.


Andrei