Arrays passed by almost reference?

[gzp]

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