An interesting consequence of safety requirements

[grauzone]

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?

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.

> So get ready to use static a lot more ;o).
> 
> 
> Andrei