On Thursday, 19 November 2015 at 15:36:44 UTC, Steven
Schveighoffer wrote:
On 11/19/15 3:30 AM, Jonathan M Davis via Digitalmars-d-learn
wrote:
On Wednesday, November 18, 2015 22:15:19 anonymous via
Digitalmars-d-learn wrote:
On 18.11.2015 22:02, rsw0x wrote:
slices aren't arrays
http://dlang.org/d-array-article.html
The language reference/specification [1] uses the term
"dynamic array"
for T[] types. Let's not enforce a slang that's different
from that.
[1] http://dlang.org/arrays.html
Exactly. T[] _is_ a dynamic array. Steven's otherwise
wonderful article on
arrays in D ( http://dlang.org/d-array-article.html ) made the
mistake of
calling the buffer that T[] points to on the GC heap (assuming
that even
does point to the GC heap) the dynamic array. And per the
language spec,
that's not true at all.
It was not a mistake :) It's how I still think of it. The spec
is confusing, and my terminology, IMO, is a much more
consistent (and accurate) way to think of it.
-Steve
Why formal definition of dynamic array caused confusion and is
inconsistent? It is well consistent with static array and other
aggregate types notions.
Consider this:
int *x = new int; // this is 'int type' ans it is 'dynamic'
int y;
int *a = &y; // and this is not 'int type'
The problem is treating chunk of heap memory as some kind of type
(dynamic in this case). Type of object determines an interface of
interacting with object while storage determines memory location
and possibly duration of lifetime. It is possible to have object
of any type to be allocated on different storages - for example,
slice does not necessarily points to dynamic array (in your
terms). C and C++ established a long tradition of such standard
notions as object, lifetime, storage and type. From system
language perspective calling memory a type (in other words, type
of object depends on where it was allocated) does not make much
sense.
