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.
Right now they only have one problem (which different people ascribe a
different gravity to) and are otherwise very expressive. Now think of
this: the MRU solves a grave issue with slices. We haven't thought of
that for years, and all of a sudden stomping is not an issue anymore. I
wouldn't be in the least surprised if someone posts in this group
tomorrow that they found a way to make ~= more predictable.
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.
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. 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.
One other thing is that it's all tradeoffs; things that are "good" in
all dimensions are in very short supply. 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". 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. Fortunately, that can be
implemented using T[] because T[] is expressive enough :o).
Andrei
