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

Sun, 28 Sep 2008 16:38:33 -0400,
bearophile wrote:
> 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)];

Unfortunately this doesn't address the issue I've faced: readLine returns a slice of an internal buffer and there's no way to notice that except by RTFM or debugging.

Sergey Gromov:
> Unfortunately this doesn't address the issue I've faced: readLine returns a slice of an internal buffer and there's no way to notice that except by RTFM or debugging.

You are right.
This is how I have mostly solved your problem in my libs. This is a lazy generator of all the combinations of the given items, taken at groups of length k:

class Xcombinations(TyItem) {
    this(TyItem[] items, int k, bool copy=true) {
    ...
    }
}

The copy argument is true by default, it means that all the arrays it yields are actual copies. So by default it acts safely but it's slower. In the not so common situations you want to go faster and you know what you are doing you can set copy to false, so the dupping isn't performed, and the code goes ten or more times faster. You have to put that third argument to false, so while you program you know what does it means.

A similar strategy may help avoid some problems with the readLine and other functions/generators. If no performance loss can be accepted then 'copy' may even become a compile-time constant, so you can use it with "static if":

class Xcombinations(TyItem, bool copy=true) {
    this(TyItem[] items, int k) {
    ...
    }
}

Bye,
bearophile

On Mon, 29 Sep 2008 02:31:59 +0400, Sergey Gromov <snake.scaly@gmail.com> wrote:

> Sun, 28 Sep 2008 16:38:33 -0400,
> bearophile wrote:
>> 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)];
>
> Unfortunately this doesn't address the issue I've faced: readLine
> returns a slice of an internal buffer and there's no way to notice that
> except by RTFM or debugging.

I think it is easy. Adopt a guide-line and make it standard (across the library or the whole language):

a) if a const slice is returned then it means that you don't own the data but someone else does. You can only read from it (const == readonly).
b) if a mutable slice is returned then you are free to modify it, you are the sole owner of it.