D2's "slice" is different than some other languages'. :)
It's okay to change/create new semantics for new languages. It's a must
have to develop new features as long as they make sense.
But think as a newbie to programming for a while.
If you've just learned of arrays and slices and hardly know anything
about memory layouts and pointers, would you understand these strange
behaviours?
OT: Actually I wouldn't even let a newbie to use GC either, as it hides
the ownership questions (as the case here with slices).
During program design one of the most crucial question is the role of
each module/class. When you have a clear view of ownerships, roles, the
design gets much better. With a GC this ownership question is postponed
or even omitted and the barriers of the modules may become very thin;
modularity/code reuse is gone. (I'm not saying that GC is bad! But more
attention must be taken during program design)
But, we must find a different entity (GC? druntime?) that makes the copies;
becaus that entity is the owner of the elements.
Exactly. And I'd prefer to distinct the owner, and the view of the array
more. Don't let the view alter the structure (int[]), and allow the
programmer to have access to the actual array (that's hidden now by the
GC/druntime ).
1) I disagree that D2 provides dynamic arrays to the programmer. The dynamic
nature of the elements are maintained on the background; but the programmers
never lay their hands on dynamic arrays.
Just as my comment above.
It gets interesting:
int[] slice2 = slice[1..$-1];
Now we have two entities that provide access to the underlying objects. This is a
"sharing relationship." In this sense, the two share the access to those
objects.
The interesting part is that, either party can leave this relationship at
will... As soon as they see unfit, they will go elsewhere and start providing
access to copies of these object.
If I want to leave the ownership let's make it explicit and write it
down in the code. Don't let the program reviewer think for hours whether
it's still the original array or some other different copy and view of it.
int[] slice2 =
slice.I_really_want_to_create_a_copy_with_2_additional_elements;
Some random thoughts:
I am not sure whether the following are your proposals for change, but I tested
them with the current implementation and they fit in the semantics as I
understand.
Actually it was a kind of proposal suggestions those fit the current
syntax. I'm not sure what's been implemented of them. They were just
some ideas I'd like to see in D2.
int[new] is the array itself (i'm not sure)
int[new] a = new int[100];
I haven't learned about T[new] yet, but I think it is discontinued. (?)
I haven't learned of T[new] either, maybe it's a different thing. I
don't know, I was not following that thread. It just simply seemed
natural after I've seen the syntax in the newsgroup.
One final comment why I really don't like the current slice implementation.
What is the undefined behaviour of a program? When you cannot tell what
is the outcome of a function knowing all the inputs. (the random seeds
is an input too :) )
And foo(int[]) is undefined, since it depends on the state of memory
fragmentation, the state of the moon, etc.
The outcome depends on weather the GC can resize the array in place or
not. Thus D has a built in feature that's undefined by nature, thus D is
undefined.
Or slice resizing creates a copy of the underlying array all the time?
Then why can't we access this array directly, i'd be much clearer and
readable what was the goal of the programmer.
ex. foo( const C classRef) tells the programmer won't thange the class,
Than why can't we have:
foo( slice ) to indicate I want to change the items in the array
foo( const slice ) for reading the items only
foo( array ) I want to alter the structure of the elements
foo( const array ) just for completeness, as it should have the same
effect as the const slice.
And for parallel programming they might also help, since for slice
access the array structure cannot change so a read access is sufficient
for the array structure (sometimes it's better to calculate something
twice, and write it twice from different threads).
And for the array use, we know, the structure might also be changed,
thus it have to be guarded by critical sections as well.
Gzp
