disable all member function calls for rvalues?

[Steven Schveighoffer]

On Tue, 22 Dec 2009 11:05:52 -0500, Michel Fortin  
<michel.fortin at michelf.com> wrote:

> On 2009-12-22 08:45:00 -0500, "Steven Schveighoffer"  
> <schveiguy at yahoo.com> said:
>
>> The point is, wrapper types shouldn't have second-class citizenship as   
>> rvalues to pointers and references.  There's got to be a way to  
>> identify  types as being lvalues even though the compiler doesn't see  
>> it that way.   If you can accomplish that, then I have no problem  
>> disallowing setting  members of true rvalues.
>
> What you need is tail const. Lvalues are similar to tail-const values:  
> can't change them, but can change what they point to. The lvalueness is  
> not transitive, so a transitive const isn't appropriate for representing  
> lvalues.
>
> Then of course you need to annotate member functions as being  
> tail-const, and there the const system becomes more complicated.

You mean head-const.  We have tail-const already (I often get them  
confused too).

But that's not exactly what I mean.  Constancy aside, if I have a wrapper  
struct like this:

class C
{
    void setX(int n){...}
    @property S s() {return S(this);}
}

struct S
{
    private C c;
    @property void x(int n) { c.setX(n); }
}

I should be able to do this:

auto c = new C;
c.s.x = 5;

Basically, s is giving a restrictive interface to a C, using the power of  
struct member functions, I can filter what functions are available or what  
they are named, or log them, or do whatever I want.  It's a wrapper type.   
If s's functions are inlined, then S has almost no overhead, it just  
provides static interface transformation.

Even if there was an annotation like:

@lvalue struct S
{
}

which hints to the compiler that S can be used as an lvalue, I'd be more  
than happy to accept Andrei's proposed restriction.

-Steve