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

[Roman D. Boiko]

On Thursday, 12 July 2012 at 17:51:32 UTC, Andrei Alexandrescu 
wrote:
> 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.

+1

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

+1. Such seams give flexibility that otherwise would be extremely 
hard to achieve.

>> 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 (Especially if it would be possible to redefine 'lazy', so 
that it would evaluate at most once.)