All right, all right! Interim decision regarding qualified Object methods

[David Piepgrass]

On Thursday, 12 July 2012 at 04:15:48 UTC, Andrei Alexandrescu 
wrote:
> Required reading prior to this: http://goo.gl/eXpuX
>
> You destroyed, we listened.
>
> I think Christophe makes a great point. We've been all thinking 
> inside the box but we should question the very existence of the 
> box. Once the necessity of opCmp, opEquals, toHash, toString is 
> being debated, we get to some interesting points:

Well, I'm not convinced it is a good idea to eliminate the stuff 
from Object, nor to remove const (I think RawObject as a base 
class of Object has merit, but to remove the Object functions for 
everyone? I'm very suspicious.)

Some problems I would point out with the idea of "eliminate the 
stuff from Object and use more templates instead":

1. Most importantly, the C++ template approach is a big pain for 
large-scale systems, because in such systems you want to create 
DLLs/SOs and C++ has neither a standard ABI nor a safe way to 
pass around template instantiations between DLLs (in the presence 
of changes to internal implementation details). Similar problems 
exist for D, yes? It's a lot easier to define a standard ABI for 
classes than to solve the cross-DLL template problem.

2. Although templates are used a lot in C++, in D programs they 
are used even more and this proposal would increase template 
usage, so I'd expect the bloat problem to increase. However, 
merging identical functions (identical machine code) might be a 
sufficient solution.

3. The need for more templates slows down compilation. We know 
this is a huge problem in C++.

4. Template bloat is no big deal on desktops but it becomes a 
bigger problem as the target system gets smaller. Maybe some 
compromise should be made to ensure D remains powerful and 
capable on small targets.

There were two proposals yesterday that I liked. Taken together, 
they address all the problems that were raised with const 
functions in Object:

1. Provide a 'safe workaround' for const, for caching and lazy 
evaluation (implement it carefully to avoid breaking the 
guarantees of immutable)
2. Provide a class modifier that makes immutable(_) illegal, so 
the class uses "logical const" instead of "physical const".