[dmd-beta] D 2.059 beta 4

[Nick Sabalausky]

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.