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.
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.
Andrei
