Congratulations to the D Team!

[Timon Gehr]

On 07/11/2012 04:16 PM, deadalnix wrote:
> On 11/07/2012 16:16, deadalnix wrote:
>> On 11/07/2012 16:04, Timon Gehr wrote:
>>> On 07/11/2012 02:58 PM, deadalnix wrote:
>>>> I don't think that is a big issue.
>>>>
>>>> Either the value isn't accessed often, and then it make no sense to
>>>> cache it, or it is accessed often and it make sense to precalculate the
>>>> cached value when building the object.
>>>>
>>>
>>> And sometimes it is not known in advance if it will be accessed at all.
>>> And this is somewhere in a class that seems unrelated to the object
>>> that wants to compute a string representation/hash value/comparison.
>>> It is not the simple cases that are an issue.
>>
>> Arguably, this is a software design problem. I never encountered a case
>> where I need to do such thing and never encountered something similar in
>> code except code that demonstrate trick or subverting language
>> features/librairies in unexpected ways (which is always fun to do, but
>> should never ends up in production or be promoted by a language/a lib).
>
> By the way, I'd be happy to be proven false, but I think the issue is
> overstated here.

Frankly, there is no real issue. It is always possible to sidestep the
built-in syntax-sugared library-supported functionality. The 
inefficiencies caused by the unused vtable slots are likely neglegible.
It's just not something one wants to do nor encourage to do.