[dmd-beta] D 2.059 beta 4

[Jason House]

On Apr 9, 2012, at 10:32 PM, "Nick Sabalausky" <bus_dmdbeta at semitwist.com> 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?

From a safety perspective, passing strict literals as "const ref" is fine. There is no output to discard. I have a vague impression that the restriction was put in place to allow some kind of optimization. I bet it's discussed in TDPL somewhere...