[dmd-beta] D 2.059 beta 4

[Jonathan M Davis]

On Monday, April 09, 2012 22:32:53 Nick Sabalausky wrote:
> From: "Walter Bright" <walter at digitalmars.com>
> 
> > On 4/9/2012 4:25 PM, Jonathan M Davis wrote:
> >> All in all, this is way too messy. Bearophile's suggestion of using const
> >> auto ref will probably work though as long as you template the function
> >> (since auto ref doesn't currently work with non-templated functions). -
> >> Jonathan M Davis
> > 
> > Templating a struct opEquals doesn't work because templates can't be
> > installed in the TypeInfo.
> > 
> > I'm beginning to think that disallowing struct literals to be lvalues was
> > a bad idea.
> 
> I didn't see any of the discussion on the matter, so I might be missing
> somthing, but my thought ATM is I don't see why...
> 
>     foo(MyStruct());
> 
> ...shouldn't be considered any different from:
> 
>     auto _tmp = MyStruct();
>     foo(_tmp);
> 
> regardless of foo's signature. That's what I would intuitively expect.
> 
> Although, I suppose the "not an lvalue" restriction could help avoid
> accidentally passing literals to something like fooInPlace and result in an
> accidental no-op. But then, not everything with a ref arg is intended to be
> a xxxInPlace function anyway. For example, opCmp.
> 
> IIRC, I think someone mentioned here earlier about it being to make structs
> consistent with int/etc. But (possibly crazy idea here) maybe that just
> means that the consitency should just work the other way: That maybe int
> literals should be usable as "ref int" args (and imply creation of a
> throwaway temp var). The "ref" *does* imply "in AND out", and if the caller
> doesn't care about the output, then why not allow an implicit throwaway
> temp?
> 
> Although, if there really is good merit to struct lits not veing lvalues,
> then maybe all we need is to wait until "auto ref" is usable for
> non-templates? (If that would even be possible...?)
> 
> Anyway, my $0.02, FWIW.

If struct literals are lvalues, then

void func(const ref S s) {...}
S foo() {...}

func(S(1)); //compiles
func(foo()); //fails

S(1) is a temporary just like the value returned by foo. Why on earth would it 
be an lvalue. It represents neither a variable nor a memory address. I believe 
that the discussion of struct literals being rvalues was near unanimous save 
for Walter. But I'd have to go digging to find the discussion.

- Jonathan M Davis