On Mon, 22 Aug 2005 18:39:34 -0400, Ben Hinkle <bhinkle@mathworks.com> wrote:
>> That said, if the slice started on a byte boundary it would be _possible_ to allow it. I doubt many people would like/accept the inconsistency there however.
>
> There is a big difference between j[] = i[a..b] and j = i[a..b] no matter
> what the byte boundaries are. Consider big-endian machines with trying to
> slice shorts and longs where the bit[] packing unit is a byte. Short is
> positioned in memory as
>   1 0
> where the number "1" means that byte stores the data starting at bit 8*1.
> Long as
>   7 6 5 4 3 2 1 0
> Assuming bit[] is made of a pointer and length with the pointer at the low
> memory value it is reverse of the endian order (bit[] is currently
> independent of endianness). Implementing bit[] with the pointer at the high
> byte and decreasing might work for setting bits but it wouldn't mesh with
> D's existing array semantics of increasing indices mapping to increasing
> memory locations. Plus resizing a bit[] with decreasing contents would be
> very different than resizing a standard array. That's why I think the most
> practical suggestion was your original restriction of only allowing the
> slicing if it is immediately copied and never exists as a bit[].

You're right. I agree.

> But then I think that's too large a restriction to be useful.

It doesn't stop you twiddling bits and it doesn't stop you forming a new variable from a collection of bits via bit copying. So, it achieves the desired goals.

It does stop you from referencing part of an existing variable then later twiddling or reading them, but then that wasn't what it was supposed to achieve, and it can be achieved with a pointer to the original variable and later slicing.

Regan