On 2/6/13 3:02 PM, Andrej Mitrovic wrote:
On 2/6/13, Andrei Alexandrescu<seewebsiteforem...@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
