Text editing [Was: Re: #line decoder]

[bearophile]

Sergey Gromov:
> This will teach me not to do research late at night. D-:

So far I have done similar bugs few times, so I think it's not your fault, such "light" slices are a bug-prone feature of D. But light slices are quite efficient and handy too. (A significant difference in performance from Numpy package compared to Mathlab comes from the fact that in Numpy slices are light (in D I miss rectangular dynamic arrays of Numpy. I think their syntax can be added without problems, a[x,y] is rectangular, and a[x][y] is not. The same works for their creation: new int[10,20] is easy to tell apart from int[10][20], but other problems may be present)).

D is supposed to do the safe thing by default (if it's not too much slow and it doesn't require too much memory) and the efficient but unsafe one on request, but in this situation I think it is doing the opposite.

So the situation can be inverted: using the normal slice syntax to denote a real copy of the slice contents, and perform a "light" slice when the programmers uses a special syntax.

Real copy of the slice:
int[] s = a[2 .. 5];

Light copy, by reference only, some possible alternative syntax:
int[] s = a[2 .. 5].light;
int[] s = a[[2 .. 5]];
int[] s = a[2 .. 5].undup;
int[] s = a[|2 .. 5|];
int[] s = a[{2 .. 5}];
int[] s = a{2 .. 5};
int[] s = a[(2 .. 5)];

Bye,
bearophile