Article about problems & suggestions for D 2.0

[Andrei Alexandrescu]

On 8/30/11 12:45 AM, Benjamin Thaut wrote:
> Am 30.08.2011 02:56, schrieb Andrei Alexandrescu:
>> On 8/29/11 4:36 PM, Walter Bright wrote:
>>> On 8/29/2011 2:22 PM, Jonathan M Davis wrote:
>>>> Certainly, for the common case, adding move constructors is a needless
>>>> complication, and I'd _very_ leery of the ramifications of the
>>>> compiler not
>>>> being able to rely on a move having the bits stay absolutely identical
>>>> (and a
>>>> move constructor would make it possible for the struct's state to
>>>> change
>>>> completely instead of really being a move). It's not necessarily
>>>> completely
>>>> unreasonable, but you appear to have found what I would expect to be a
>>>> _very_
>>>> abnormal use-case.
>>>
>>> Andrei and I have talked about adding move constructors, but I agree
>>> with you that it really seems to be a tar pit we'd really like to avoid.
>>> C++ has a lot of subtle problems caused by supporting this, not the
>>> least of which is efficiency problems.
>>
>> The language semantics make move construction unnecessary. Values are
>> moveable as bits through memory.
>>
>> I think the article is a bit confused on this particular matter. Only
>> objects with value semantics are freely moveable, so they have no direct
>> interaction with the garbage collector. What they might want to do is to
>> hold a pointer/reference _inside_ of them and deregister that pointer
>> with the garbage collector with the destructor. Due to the indirection,
>> it doesn't matter where the object is in memory.
>>
>>
>> Andrei
>
> I don't see implementing a GC as that of a abnormal use case.

Implementing a GC is an exceedingly rare privilege.

> Especially
> given the fact that D is a garbage collected language and could benefit
> a lot from features that make implementing a GC easier.

I don't believe D should be in the business of adding features that make 
implementing a GC easier. Such a task is extremely specialized; if the 
language allows it, that's about enough.

> In thise special
> case the discussed struct would be a wrapper for every reference on the
> stack, so the references can be tracked by the GC and changed if
> neccessary. Adding a level of indirection to every reference would
> greatly impact performance because it would most likely add yet another
> cache miss when accessing a reference. I'm very well aware of D's
> concept of structs. But sometimes this concept is very bad for
> performance, that is what I wanted to point out. Adding a move
> constructor which most of the structs won't even use, should be less of
> a performance impact, then adding another level of indirection.

Clearly adding an extra level of indirection would be harmful, no two 
ways about it. But essentially the object model is what it is: there are 
value types that move, and there are reference types that don't. Deal 
with it. If you need to implement a garbage collector, you can't do it 
with move hooks because they're not provided. In a subtle way it's a 
given, although I totally understand how this or that hook would make 
your work easier. I don't find the complaint valid at all.


Andrei