On Apr 9, 2012, at 10:32 PM, "Nick Sabalausky" <[email protected]> wrote:
> From: "Walter Bright" <[email protected]> >> >> 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... _______________________________________________ dmd-beta mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/dmd-beta
