DIP25 draft available for destruction

[Andrei Alexandrescu]

On 2/6/13 3:02 PM, Andrej Mitrovic wrote:
> On 2/6/13, Andrei Alexandrescu<SeeWebsiteForEmail at erdani.org>  wrote:
>> Probably it'll need a fair amount of tweaking. Anyhow it's in
>> destroyable form.
>> http://wiki.dlang.org/DIP25
>
> Originally I thought addressOf was only planned for safe functions,
> but for system too?
> This will likely break almost every library in existence. And
> interfacing with C will become severely handicapped.

That's a good point.

> Btw, using pointers can actually lead to code which is clearer in its intention:
>
> void foo(int* x, int* y) { }
> void test(int x, int y)
> {
>      foo(&x,&y);  // we know foo might modify these parameters
> }
>
> Since we don't have "ref" at the call site, using ref parameters can
> lead to code which isn't immediately understood at the call site:
>
> void foo(ref int x, ref int y) { }
> void test(int x, int y)
> {
>      foo(x, y);  // can the parameters be modified? it's not clear from
> the call site
> }

I think there's no way to have it both ways. You'll have to get used to 
the new style and make it a requirement instead of a stylistic 
preference. Pointers are what they are, and they're not appropriate for 
code that offers guarantees. We could define a bunch of special rules 
for pointers in @safe mode, but I think it's cleaner this way: ref is 
for safe code, if you want to mess with things use pointers.

> Also the DIP argues that addressOf solves the @property issue w.r.t.
> return values. I've proposed we use an .addressOf property which only
> works on @property functions, and I saw no arguments against it.

There aren't, but a library approach is better than a magic work, all 
other things being equal.


Andrei