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
