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

[Andrei Alexandrescu]

On 7/12/12 1:40 PM, David Piepgrass wrote:
> 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.

The thing is, that can be done in an opt-in manner. People who want 
methods in the root of the hierarchy can define a root that defines 
them. But there's no way to opt out of inheriting Object. Basically it's 
nice to not force people to buy into a constrained environment without 
necessity.

> 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.

Yah, I think we have a pretty good attack at this problem.

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

I, too, think this is a concern.

> 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.

I think virtuals are an equally, if not worse, problem in 
memory-constrained systems. The simple solution people choose for such - 
they use them judiciously. Here actually templates may be at an 
advantage because of their opt-in quality.

> 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)

We should explore this option in any case. At this point I'm starting to 
believe (a) we're doing the right thing by marginalizing the four 
methods aside from this issue, (b) caching is good for other things than 
this particular problem.

> 2. Provide a class modifier that makes immutable(_) illegal, so the
> class uses "logical const" instead of "physical const".

I think this would be considerably trickier.


Andrei