Is the address-of operator (&) really needed?

[Jonathan M Davis]

On Saturday, June 02, 2012 00:23:44 Artur Skawina wrote:
> I've never had to use 'auto ref' and did not even bother to check that page
> before writing my first reply - that's how insane any other interpretation
> would be; it really cannot work any other way. (unless the arguments type
> has an attribute specifying ref or value semantics, but D does not have
> those yet)

Since the whole purpose of introducing auto ref was to do more or less what 
const ref does in C++ and try and pass stuff efficiently without caring whether 
it was an lvalue or rvalue, I'm not sure that it matters much, though 
arguably, the fact that it doesn't automatically make it all const would make 
that less sane. Though honestly, given that auto ref can only work with 
templates, I'd argue that it's pretty much a failure as far as its mandate 
goes.

> > But tt doesn't really matter. getopt can't be implemented using auto ref
> > regardless of how defined it is what's ref and not. It uses compile-time
> > reflection to examine the arguments and determine what they're for. Even
> > passing a flag as an lvalue would then make it a ref, making it look like
> > it was supposed to be taking an argument rather than being the string for
> > the flag. By taking pointers, it's explicit, and it works. That won't
> > work with
> I'm probably the last person anyone could suspect of having pointerphobia...
> :) And using explicit pointers instead of refs as part of an interface is a
> good thing, usually much better than (ab)using refs for this.

I was paying enough attention to who I was responding to. The OP seems to be 
very against &.

> That doesn't
> mean however that it cannot be done. So, what is the problem with this
> 'flag'? AFAICS (never looked at the getopt code) it always receives the
> arguments in pairs, where only the second value needs to be a lvalue.
> (getopt options can be skipped over, and can not appear in between). Where
> is the problem? The fact that option strings could be passed by ref is
> harmless.

If you specifically watch for the getopt options and compile-time reflection 
properly flags as that enum type and nothing else as that enum type (I'm not 
quite sure where that stands, given how enums can't always seem to decide 
whether they're enums or not), then it may be possible to make getopt work 
based purely on positioning (it's been a while since I looked at the code, so 
I don't know quite what it's doing). But it's impossible to make it work based 
on type. So, even if you can make getopt work, the general problem of not 
being able to use ref on some but not all of the arguments to a variadic 
templates remains. You'd have to add a way to the language to indicate that an 
argument should be passed by ref - which may not be a bad idea. It would only 
make sense with templates, since that's the only place that the type is in 
flux, but it might be worth having. getopt works just fine with pointers though.

- Jonathan M Davis