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?
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.
_______________________________________________
dmd-beta mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/dmd-beta
