DIP 1014

[Jonathan M Davis]

On Sunday, September 30, 2018 1:35:28 AM MDT Shachar Shemesh via 
Digitalmars-d wrote:
> On 30/09/18 10:26, Manu wrote:
> > Other implementations make much better use of that built-in space by
> > not wasting 8 bytes on an interior pointer for small-strings.
>
> I will point out that a pointer that *sometimes* points to an internal
> member was one of the use cases I documented when I submitted the DIP.
>
> Starting a long discussion about the merits of the design is a bit
> off-topic. I will point out that branch prediction considerations
> *might* make this a wise choice, despite the loss of 8 bytes of
> potential storage.
>
> Either way, this is a design that is highly sensitive to precise use
> pattern, which, admitably, GNU's std::string probably can't know.

I think that the key thing here is that if GNU's std::string is using a
design like this, it's that much more critical that we have a way to hook
into moves to do stuff like adjust pointers. It's one more example of a real
world use case where the DIP (or something like it) is needed, or there are
things that we simply won't be able to do in D - and given the push to
interface with C++, it's that much more important. And while a discussion
could certainly be had as to whether GNU's design decision was a good one or
not, it's secondary to what really matters here, which is what the state of
the DIP is how we're going to deal with interfacing with this C++ code. We
need to worry about how to interface with it whether it's the best design
ever or whether it's the worst design ever - and we have to take into
account the fact the its design could actually change in future versions if
they decide that a different way is better (e.g. GNU could change to match
other implementations, or other implementations could change to match GNU,
depending on what actually turned out to be best in practice when all of the
various factors were taken into account - including developers making future
decisions that aren't necessarily good ones; we have to interface with the
code whether it's good or bad).

All in all though, if anything, I have to think that this issue increases
the chances of the DIP being accepted given the importance that Walter and
Andrei have been placing on interfacing with C++. And having it come up
while they're in the middle of discussing it probably doesn't hurt - though
maybe they were already going to accept it. I don't know. Personally, while
I tend to think that it's generally better to avoid designs where opPostMove
is necessary if possible, I think that the case was well made that we need a
solution like it in certain cases, and if we want to interface with C++,
which can do more or less arbitrary stuff in its move constructors, I don't
see how we can avoid having an analogue unless we want to give up on
interfacing with that code without an extra compatibility layer.

- Jonathan M Davis