On Wednesday, February 06, 2013 02:38:17 Andrei Alexandrescu wrote: > Probably it'll need a fair amount of tweaking. Anyhow it's in > destroyable form. > > http://wiki.dlang.org/DIP25
Overall, the ref part seems good, but I'm highly skeptical of the part on addresses. The main point I'd raise about the ref portion is that module-level variables need to be grouped in with the static variables. You seem to have marked some module-level variables as scope in the examples, but static has no effect on module-level variables. As for the addresses, it seems very bizarre to create a function for doing what & does and then make & legal only in very restricted circumstances. Having a safeAddressOf for some set of restricted circumstances might make sense, but couldn't the compiler just detect that & was safe under those circumstances? If the compiler can determine that it's @safe using the function, it should be possible for it to determine it without. And disallowing & even in @system code is _way_ overkill. The compiler is already able to detect at least some unsafe cases (e.g. taking the address of a local variable), and it's incredibly common to need to do some of those when interacting with C code (e.g. taking the address of a local variable and passing it to a C function). If the problem is ambiguities between taking the address of a function and the address of its return value, then I'd think that it would be much cleaner to just create a __trait for getting the address of a function. It's needed far less than taking the address of a variable, and the difference between & and addressOf is just going to sow confusion. It definitely seems like overkill to me to introduce a function for doing what & already does just to deal with the difference between taking the address of a function and taking the address of its return value. So, I'm in favor of the changes to ref, but I definitely don't like what this DIP does with &. - Jonathan M Davis
