Three separate implementations of bit array slicing have been posted here and on digitalmars.D.bugs, as replacements for the current, completely non-functional 'implementation' that's worse than having no implementation at all.  And it definitely seems that Walter still needs help in deciding which one to hook up.

The three implementations tackle the problem in different ways.  They are:

1. http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/3782
Restrict slicing to slices beginning on byte boundaries.

Pros:
- ABI consistency with other array types*
- Semantic consistency with other array types (slicing into arrays), in the cases that would be supported

Cons:
- Not a general solution
- Adding a restriction to the spec would be (arguably) a step backward

2. http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/313
Copy slices that aren't byte aligned.  (Actually, it copies all slices that don't start at zero, but it's trivial to change otherwise.)

Pros:
- Can arbitrarily slice a bit array
- ABI consistency with other array types*

Con:
- Semantic inconsistency - slices generally copy the array, and don't slice into it

3. http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/495
Include a bit offset in each bit array/pointer reference.

Pros:
- Can arbitrarily slice into a bit array
- Semantic consistency with other array types, both by slicing into arrays and by being unrestricted
- Doubles as a means of enabling bit pointers to point to arbitrary bits, taking semantic consistency even further

Cons:
- Takes up slightly more memory
- ABI wouldn't match other array types*

*Debatable.  My opinion is that, considering that bits are naturally a special type, with characteristics not shared by any other type (atomic, derived or compound), we could get away with defining a special ABI for bit arrays and pointers.


Of course, these might not be all the pros and cons.

Here are the votes so far:

Approach 1:
Arcane Jill

Approach 2:

Approach 3:
Stewart Gordon

Please cast your votes!

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment.  Please keep replies on the 'group where everyone may benefit.

In article <ce2sm1$t3d$1@digitaldaemon.com>, Stewart Gordon says...

>Here are the votes so far:
>
>Approach 1:
>Arcane Jill

Did I vote for this? Hmmm. I don't remember doing that. I remember posting a workaround which operated along the lines of Approach 1, but that doesn't mean it's my favorite.

Anyway, even if I did vote for (1) once, I'm allowed to changed my mind.

Gotta be (3), obviously. Complete consistency with all other types in all respects. The ABI difference only means that bit* can't be cast to byte* and back again without losing information. But so what? Anyone who's used to writing typesafe C++ code will know that, in general, casting A* to B* and back to A* is rarely guaranteed to be safe anyway.

Arcane Jill

On Mon, 26 Jul 2004 13:16:00 +0100, Stewart Gordon <smjg_1998@yahoo.com> wrote:
> Three separate implementations of bit array slicing have been posted here and on digitalmars.D.bugs, as replacements for the current, completely non-functional 'implementation' that's worse than having no implementation at all.  And it definitely seems that Walter still needs help in deciding which one to hook up.
>
> The three implementations tackle the problem in different ways.  They are:
>
> 1. http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/3782
> Restrict slicing to slices beginning on byte boundaries.
>
> Pros:
> - ABI consistency with other array types*
> - Semantic consistency with other array types (slicing into arrays), in the cases that would be supported
>
> Cons:
> - Not a general solution
> - Adding a restriction to the spec would be (arguably) a step backward
>
> 2. http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/313
> Copy slices that aren't byte aligned.  (Actually, it copies all slices that don't start at zero, but it's trivial to change otherwise.)
>
> Pros:
> - Can arbitrarily slice a bit array
> - ABI consistency with other array types*
>
> Con:
> - Semantic inconsistency - slices generally copy the array, and don't slice into it
>
> 3. http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/495
> Include a bit offset in each bit array/pointer reference.
>
> Pros:
> - Can arbitrarily slice into a bit array
> - Semantic consistency with other array types, both by slicing into arrays and by being unrestricted
> - Doubles as a means of enabling bit pointers to point to arbitrary bits, taking semantic consistency even further
>
> Cons:
> - Takes up slightly more memory
> - ABI wouldn't match other array types*
>
> *Debatable.  My opinion is that, considering that bits are naturally a special type, with characteristics not shared by any other type (atomic, derived or compound), we could get away with defining a special ABI for bit arrays and pointers.
>
>
> Of course, these might not be all the pros and cons.
>
> Here are the votes so far:
>
> Approach 1:
> Arcane Jill
>
> Approach 2:
>
> Approach 3:
> Stewart Gordon
Regan Heath

I believe semantic consistency is a primary concern.
IMO if you need this behaviour (arbitrary slice without copying) you will not mind paying the memory cost. As for the ABI difference I agree with Arcane Jill.

Regan.

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/