D array expansion and non-deterministic re-allocation

[Leandro Lucarella]

Andrei Alexandrescu, el 19 de noviembre a las 18:25 me escribiste:
> Leandro Lucarella wrote:
> >Andrei Alexandrescu, el 19 de noviembre a las 17:13 me escribiste:
> >>Leandro Lucarella wrote:
> >>>dsimcha, el 19 de noviembre a las 23:21 me escribiste:
> >>>>Face it, D is a close to the metal language.  Any attempt to define the spec at a
> >>>>purely abstract level without reference to any implementation details, and without
> >>>>leaving certain details implementation defined is absurd.  I think people need to
> >>>>face the fact that you can't have close-to-the-metal flexibility and performance
> >>>>and at the same time far-from-the-metal strict separation of specification from
> >>>>implementation details.
> >>>Yes, but I think this is a place where you are doing early optimization at
> >>>the expense of usability. You can always do the slice-thinguie yourself if
> >>>you are that needed for speed that you can't afford an extra indirection
> >>>when using an array (which will be the only overhead if T[new] were
> >>>implemented as a pure reference type).
> >>>
> >>>I think the cost here in terms of usability if far higher than the little
> >>>performance you loose, specially when you can overcome the issue for those
> >>>weird cases where you need it.
> >>I think one aspect that tends to be forgotten is that built-in
> >>arrays are the lowest abstraction - really just one small step above
> >>pointers. Efficiency lost there is lost forever. That's why I
> >>consider the current design adequate and the proposed designs less
> >>so.
> >
> >I don't think so, slices (a view over somebody elses memory, no appending)
> >should be the lowest level abstraction.
> >
> >>In other words: you can build a more convenient facility on top of
> >>T[], but you couldn't build a more efficient facility on top of a
> >>convenient one. I think D made the right choice with built-in
> >>arrays.
> >
> >I don't. Current built-in arrays are both dynamic arrays and slices, which
> >is what messes all up.
> 
> Well it also makes arrays/slices quite capable.

Yes, capable of introducing bugs specially =)

> Right now they only have one problem (which different people ascribe
> a different gravity to) and are otherwise very expressive.

Nobody is judging the expressiveness of arrays, the bug-prone semantics
is the problem.

> Now think of this: the MRU solves a grave issue with slices.

You are using arrays and slices interchangeably on purpose, right? I hate
you! =)

> We haven't thought of that for years, and all of a sudden stomping is
> not an issue anymore.

And suddenly you are tying array implementation with the GC. You are
making things worse, not better. This whole issue reminds me to this blog:
http://thereifixedit.com/
=P

> I wouldn't be in the least surprised if someone posts in this group
> tomorrow that they found a way to make ~= more predictable.

Split slices and arrays, add a capacity field to arrays, remove appending
from slices. There.

> >But I'll drop the subject, once again, for the sake of... well, everybody
> >;)
> 
> I encourage you to further your point (while in understanding that
> your existing arguments and proposals have been understood). This is
> the best time to make a contribution to D's design.

I keep replying just because I can't control myself, but I really think
it's pointless, I have said (as many others) several times what are the
problems and what would be a nice solution. You just find the solution
unsuitable and think the cache is good enough.

> We may as well undefine "~" or "~=" or both for arrays if there's
> enough arguments and evidence that it's a problem to keep them.

I think that would be very bad. For once, I thought "~" where out of
discussion, because it always create a new temporal (like any other binary
operator), so I can't see a problem with it. And I hope you are only
seeing as a possibility to remove "~=" from slices, making possible for
a library array type to define it. I can totally lived with that. If the
array type were imported in object.d it would be even better.

> When making proposals just keep in mind one important thing: with the
> context that you (all) have accumulated regarding this discussion, a lot
> of things seem very easy to understand, which are really weird when just
> starting with the language.

Please, name them! And BTW, understanding the MRU cache (and trying to
predict it) will be any easier?

> One other thing is that it's all tradeoffs; things that are "good"
> in all dimensions are in very short supply.

I know that! This discussion is just because some think one tradeoff is
better than the other.

> With arrays, we may be in the position of choosing a solution that won't
> please everyone.  The question right now is "which 5% of users you will
> disappoint".

I really think more than 5% of the users will hit the weird half value
half reference semantics of slices, but, of course, I'm making this
figures up, just like you did ;)

> As for reviving T[new], I believe that, unless some new insight comes
> forward, practically that ship has sailed. That doesn't preclude
> defining a library type that is a more encapsulated array.

I don't care about T[new], I'm fine with a library defined type. Just
remove appending from slices (and make .length read-only).

> Fortunately, that can be implemented using T[] because T[] is expressive
> enough :o).

...

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Relax.
I'll need some information first.
Just the basic facts.
Can you show me where it hurts?