dsimcha Wrote:
> == Quote from Andrei Alexandrescu ([email protected])'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...
