rvalue types

Simen Kjærås simen.kjaras at gmail.com
Mon Mar 12 18:56:17 UTC 2018


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


More information about the Digitalmars-d mailing list