February 11, 2013
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
Next ›   Last »
1 2 3 4 5 6 7 8