DIP25 draft available for destruction
Jonathan M Davis
jmdavisProg at gmx.com
Mon Feb 11 10:20:19 PST 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
More information about the Digitalmars-d
mailing list