I hoped for a little bit more feedback about the article itself.
Especially about the move constructor I suggested. Does anyone see a need for this, or is it just me?

-- 
Kind Regards
Benjamin Thaut

On 8/27/2011 10:14 AM, Benjamin Thaut wrote:
> Comments and criticism welcome


This guy wants to contact you:

http://www.reddit.com/r/programming/comments/jwkvx/suggestions_for_the_d_20_programming_language/c2g2wos

On Monday, August 29, 2011 13:35 Benjamin Thaut wrote:
> I hoped for a little bit more feedback about the article itself. Especially about the move constructor I suggested. Does anyone see a need for this, or is it just me?

Honestly, I find the fact that you're writing code which relies on the address of a variable on the stack a bit scary. Normally, that is a _bad_ idea. Now, you're obviously doing something quite abnormal, so it may be a good idea in your case, but you're definitely not doing something which your average programmer is going to need to do. And the fact that structs can be moved by having their bits copied around is a definite boon for efficiency. Adding move constructors would definitely complicate things. If there were enough use cases for them, then they may be worth adding, but at this point, the compiler definitely relies on the fact that it can move a struct without affecting it, so any code which relies on a struct _not_ moving is likely to be broken. The ramifications of adding move constructors are likely far from trivial.

Personally, I'd argue that it doesn't make any more sense to expect that a struct's location have _anything_ to do with its value, and that if you want to rely on its location, then you need to put it in a location that you can rely on. If anything, I'd argue that your structs should just have a variable identifying them if you want to have them be uniquely identifiable, but I don't really understand what you're doing.

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.

- Jonathan M Davis

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.

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

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. Especially given the fact that D is a garbage collected language and could benefit a lot from features that make implementing a GC easier. 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.

-- 
Kind Regards
Benjamin Thaut

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

Mehrdad Wrote:

> I feel like you hit the nail on the head. I feel the same way about const.
> 
> Transitivity is beautiful on the outside, but I can never actually get
> it working, so I just make everything non-const. I have to sometimes do
> this even in Phobos itself, because the compiler complains about
> something random caused by transitivity.
> I also fail to see what /problem/ it's trying to solve. The DigitalMars
> website simply states:
> 
> "With transitivity, there is no way to have a const pointer to mutable int."
> 
> But... so what? Maybe it should actually explain the benefit, since I can't figure it out on my own. (The related discussion on "head-const" and "tail-const" seems completely irrelevant to the topic."
> 
> C++'s non-transitivity seems to be quite type-safe, even if unintuitive to the beginner (which I don't think it is). I *never* ran into issues with it.

In C I had to cast away const because constness is built into the struct itself - if you want the struct to be accessed as readonly. In D transitive const is transparent - you can have the save structure both readonly and mutable.

On Aug 27, 2011, at 10:14 AM, Benjamin Thaut wrote:

> After having used the D 2.0 programming language for a year now and having completed 3 projects with it, I wrote a small article about the problems I had with the D 2.0 programming language and what suggestions I have to improve it.

"Either the builtin assert should be configureable so that it triggers a breakpoint before throwing the exception, or there sould be a way to built a custom assert"

You can use core.exception.setAssetHandler to override the default assert behavior.  This is deprecated, however, because to my knowledge no one has ever used it and because you can't actually return from this handler--you must throw.  This is because DMD doesn't generate a valid call stack around the assert call for efficiency reasons.

On Aug 27, 2011, at 10:14 AM, Benjamin Thaut wrote:

> After having used the D 2.0 programming language for a year now and having completed 3 projects with it, I wrote a small article about the problems I had with the D 2.0 programming language and what suggestions I have to improve it.

Here's another one:

"8. std.concurreny TID does not support shared"

I really need to fix this.  It's a pain though, for the reasons related to the ones you mention in "5. Shared".  A tid, for example, fronts a message queue object that has some shared interface elements and some unshared interface elements.  The shared portion, rather than labeling functions as synchronized, uses synchronized internally to make the mutex use as fine-grained as possible.  And the logically unshared portion only synchronizes when accessing the shared data in the object.  So to make Tid work with shared I would basically have to label the shared methods as shared and re-evaluate the ASM output once the compiler inserts memory barriers, and cast away shared when accessing the message queue from within its owner thread.  What gets me about all this is that rather than helping me, the type system is working against me.  I love shared as far as its use for globals is concerned, and for concrete variables, but not so much for classes.