On Saturday, 28 July 2012 at 20:59:15 UTC, Dmitry Olshansky wrote:
Great! But I strongly suggest to repost it in d.D newsgroup as
it has wider audience and is more appropriate for reviews.
I was thinking of not bothering Andrei or Walter while i fixed
other issues on it before bringing more major ones forward (which
is why i brought it to D.learn), but re-posting it there is easy
enough
My solution is make slices different type e.g. BitSlice. It's
always reference to the original BitArray. Array itself still
can be either compact or not. All operations with slice go to
array (and still check if they can use word-aligned speed up).
How does it sound?
Someone else also suggested making the slice different (Meaning
a new Bitarray always is at max compact size). Since we need at
least a single flag to determine if the array is compact or array
reference, there would be a larger loss which the current
offset/maxOffset handle quite nicely filling in that space.
Making BitSlice separate suggests BitArray would be the bare
minimum (canUseBulk, length, and index operations) while bitSlice
would handle all others. But if you do that, either BitSlice
would have to be inherently convertible to BitArray if you want
to pass it to a function that expects a BitArray. I'm hesitant to
do it, but if there's a strong enough argument for it I wouldn't
refuse it.
opCat isn't it just operator "~" and "~=" ? You can use
opOpAssign for "~=" IRC.
Yes, I think opAssign is used for ~= already, but doing the
following requires opCat and opCat_r.
BitArray a; //filled with something
auto x = true ~ a;
auto y = a ~ true;
I just can't get it to accept it (for whatever reason). Compiler
bug?
I suspect to!string wasn't CTFEable. Regardless you can catch a
word from Andrei Alexandrescu on the main D newsgroup who (I
think) came up with it in the first place.
If we can use the std.string functions I'll replace them all :)
(As I was just following the theme since they were present).
I'll move this to the D group and see what we get for this.
