std.container.RedBlackTree versus C++ std::set

[Dan]

On Friday, 15 February 2013 at 20:58:30 UTC, Jonathan M Davis 
wrote:
>
> I should probably add that bringing up discussions on how to 
> solve problems in
> the language can be of benefit, because they often result in 
> good discussions
> that help lead toward a solution, and that can lead towards 
> that solution
> ending up in the language (and depending on the discussion 
> Andrei and/or
> Walter will get involved). But simply asking them about the 
> state of things or
> essentially contronting them and trying to get them to give 
> official statements
> on their plans doesn't generally work. If nothing else, they 
> simply don't
> generally say what they're planning to do before they've 
> actually decided on
> it. They might start discussions to discuss something that 
> they're
> considering, but they're unlikely to state any kind of actual 
> plans before
> they've actually decided, which generally means no official 
> statements about
> what's coming or planned.
>
> - Jonathan M Davis

Well, that is a somewhat passive yet diplomatic stance. If the 
suggestion is - "get involved, suggest a fix or a solution and 
maybe you'll get your answers" that is reasonable. But for my 
part, I am not a language developer - just a language user and 
fan of D who is betting on D by using it for my livelihood. 
Regarding postblits - you've mentioned several times that Andrei 
and Walter have discussed and have a solution in the works. Does 
it make sense to go do a DIP or something just to illicit 
feedback on a topic? You have some of the most helpful responses 
I've seen on the group - extremely detailed and accurate. Thanks. 
However, being in the know you sometimes you let slip a little 
bit here and there that causes me to give pause and at a minimum 
want to get more information. Like "And Walter was actually 
arguing at one point for making it illegal (probably by getting 
rid of postblit all together - I don't remember the details)".

It is not unreasonable for users to want to know what is the 
future direction for a certain at risk feature. Regarding a 
suggestion for postblit/copy ctor to get things going here is 
mine:

- Implement copy constructors for structs. Allow for overloading 
on 'this' and 'const this', but no qualifier on the constructor 
itself.
- Allow the user to @disable copy constructors.
- Provide for a default copy constructor that does regular copies 
of fundamental types, shallow copies of arrays and associative 
arrays,  and calls corresponding copy constructors (or postblits 
during some grace period).

In terms of migration path:

- Allow the struct designer to choose to use either postblit or 
copy constructor but not both. For the case of using them to 
provide deep copy semantics the approaches are different. For 
postblits you are asking - "what fields do I need to copy" with 
the comfort of knowing all other fields were already copied with 
the blit. For copy constructors it is different because you have 
to think about all fields since a blit will not have happened 
first. To ease the transition provide the ability for the copy 
constructor to call blitSourceIntoThis(source).

- Leave postblits alone. Allow them to continue as is and phase 
them out 1 or more years after successful implementation of copy 
constructors

- Often the only purpose of the copy constructor is to do a deep 
copy. This could easily be provided by the compiler or phobos. 
Further, consider standardizing on the ".dup" and ".idup" 
conventions for this purpose.

Thanks
Dan