On Monday, 12 March 2018 at 18:00:02 UTC, Steven Schveighoffer
wrote:
So if I could rephrase to make sure I understand: An rvalue
type is one that you can never assign to a variable. As soon as
you try to "store" it somewhere, it becomes a new type that is
returned by its "get" function.
In this case, once it gets passed into any function that is
*not* a member function, it decays to the designated type?
Exactly.
I think this would solve the issue, and help with the property
debate, but it would have to trim out all the intermediary
stuff. I wonder instead of types which you don't want to exist
anyway, you could find a better way to formulate this.
It's easy to imagine some patchwork solutions - going back to the
property discussion I mentioned that allowing alias this and
operator overloads on named mixins would enable properties to
work as if they were implemented with rvalue types. In the same
vein, we could imagine a solution for chaining operators:
struct BigInt {
BigInt opChain(string[] ops, T...)(T args)
if (allSatisfy!(isBigInt, T) && ops == ["^^", "%"])
{
return powMod(this, args);
}
}
This would take care of those two cases, but don't offer a
solution to the WidgetBuilder example. It might be possible to
find a similar one-off solution there, but I'd rather have a more
general solution that might be useful in cases I haven't yet
thought of.
--
Simen
