disable all member function calls for rvalues?

[Jason House]

dsimcha Wrote:

> == Quote from Andrei Alexandrescu (SeeWebsiteForEmail at erdani.org)'s article
> > There is a wart in D I'd like to eliminate. Unfortunately, that would
> > also eliminate some valid uses.
> 
> This is the problem, with this feature and with a lot of other "safety" features
> that have been considered.  Having lots of static checking, etc. is good if and
> only if it doesn't get in the way too much when the programmer **does** know what
> he/she is doing.  Yes, this limitation would prevent some bugs, but it would get
> in the way very frequently as well and be an extremely annoying piece of syntactic
> salt.  Given the choice I'd rather have to debug a few more bugs in corner cases
> than have the language reject lots of valid cases.
> 
> Of course, there's room for intermediate solutions:
> 
> 1.  Allow member function calls iff the function is const.  For example, the
> following would still work:
> 
> struct A {
>     string toString() const {
>          return "A";
>     }
> }

immutable functions too.

 
> struct B {
>     A getA() @property {
>         return A.init;
>     }
> }
> 
> B b;
> string s = b.getA().toString();
> 
> 2.  Special case opAssign, since this clearly makes no sense for rvalues.
> 
> 3.  If consistency is the main concern, make other ref rvalue binding more
> permissive instead.

An alternate I was thinking about was disallowing non-const/immutable functions with void return type. They seem the most probable to be doing bad things.

Some may want the read portion of a property to be callable on an rvalue. That could allow use of "logical const" by convention...