Walter Bright írta:
The purpose of T[new] was to solve the problems T[] had with passing T[]
to a function and then the function resizes the T[]. What happens with
the original?
I've tried to follow the T[], T[new], T+slice discussion, but i'm lost,
I don't think if it's a good idea, to extend the language with all kind
of decorated version of the same object ( scope (*T)[scope new][1..$] :) )
"It will tell you for instance how to describe something that was about
to happen to you in the past before you avoided it by time-jumping
forward two days in order to avoid it. The event will be described
differently according to whether you are talking about it from the
standpoint of your own natural time, from a time in the further future,
or a time in the further past and is further complicated by the
possibility of conducting conversations whilst you are actually
travelling from one time to another with the intention of becoming your
own father or mother." Douglas Adams - The Hitchhiker's Guide to the Galaxy
Just an idea to simplify this whole thing, maybe it's whole wrong, but
who knows... :)
Instead of creating new types of arrays we have already two: static and
dynamic. A dynamic version can be resized (restructured) any time, the
static has a fixed size, thus the dynamic version works as a class and
the static version works as a struct for either in,out,ref/etc.
To create slices, slices those references the whole array i'd introduce
a new type (as there is something like this): range!(T). A range is
actually an inner class of the array implementing an IRange(T) interface
with the usual popFront, front, etc. For a general class if one wants to
add range, he just have to provide an onRange (onSlice) function.
As the range interface itself provides the opIndex, opAssign, opXAssign
etc., they can be implemented as desired and no more opSliceAddAssign
and other decorated function's are required. Even more as the range is
an inner class of the array (and knows about the array), a finer tune of
what_shall_happen_when_my_referrer_array_is_resize policy can be created.
As the range itself can work as an array, range[1] (or maybe even
rang[1..2], calling the IRange!(T).onRange() ) it can be used as an
array whose structure (length) cannot be altered as desired for T[]
ex:
T[] a; // is a dynamic array as before
range(T) s1 = T[1..2]; // the slice from 1..2
range(T) s1 = T.opRange(); // the slice representing the whole range
foo( T[new] a ) is same as foo( T[] )
foo( T[] ) would be replaced by foo( range(T) ) and thus cannot be resized
furthermore
foreach( a; array )
translates to something like ->
foreach( a; a.onRange() )...
foreach( a; array[1..2] )
translates to something like ->
foreach( a; a.onRange(1,2) )...
foreach( a; array[1..2,3..4] )
translates to something like ->
foreach( a; a.onRange(1,2,3,4) )...
array[1..2] += 1
translates to something like ->
array.onRange(1,2).opAddAssign(1);
It'd be also great to create more then one onRange implementation of a
class ex: matrix.opRangeRowWise matrix.opRangeColumnWise, but i don't
know how to select the appropriate one in a foreach loop "automatically":
foreach( a; mx.rowWise ) ->
mx.selectRange(name : string) { mixin( "onRange" ~ name ) }
foreach( a; ma.selectRange("rowWise")(1,2) )...
As a conclusion: please don't create any more array type, we have just
enough. We have already all the features in the language to express both
the desired and explained (above) behaviour. Only the syntax should be
cleared out. Using the same notation multiple times with small
decorations is not a good idea, and makes things confusing.
Thanks.
