"Janice Caron" <caron800@googlemail.com> wrote in message news:mailman.583.1210419927.2351.digitalmars-d@puremagic.com...
> On 10/05/2008, Me Here <p9e883002@sneakemail.com> wrote:
>> Really? Which documentation are you reading because the documentation on
>> my
>>  harddrive that D1/Phobos
>
> Oops. Using D2.
>
> D2 has bitfields. You might want to consider moving up. :-)

You don't *have* to use D2 in order to use bitfields.  There's also the std2 project (http://www.dsource.org/projects/std2) which ports many of the new modules in phobos 2, including std.bitmanip, to D1.

On 10/05/2008, Sean Kelly <sean@invisibleduck.org> wrote:
> > That is an entirely separate subject. There is a proposal on the table
>  > suggested by Steven Schveighoffer and myself which addresses that very
>  > problem, and our proposal sounds similar to your romaybe. However,
>  > that is not relevant for std.string.
>
> It's relevant in that the implementation of std.string could benefit from
>  the proposal, were it implemented.

Not so. The invariant versions will use copy-on-write. That is a huge, huge, plus for invariant strings, and no one wants to lose it. At the other end of the spectrum, mutable char arrays offer the possibility of modify-in-place, which invariant clearly cannot do. There is no way that Steven's/my inout proposal would be sufficient to achieve all that is needed for std.string.

Jarrett Billingsley wrote:
> "Janice Caron" <caron800@googlemail.com> wrote in message news:mailman.583.1210419927.2351.digitalmars-d@puremagic.com...
>> On 10/05/2008, Me Here <p9e883002@sneakemail.com> wrote:
>>> Really? Which documentation are you reading because the documentation on my
>>>  harddrive that D1/Phobos
>> Oops. Using D2.
>>
>> D2 has bitfields. You might want to consider moving up. :-)
> 
> You don't *have* to use D2 in order to use bitfields.  There's also the std2 project (http://www.dsource.org/projects/std2) which ports many of the new modules in phobos 2, including std.bitmanip, to D1. 

Yes, it looks like std.bitmanip is available in std2.  But not everything is.

The project is kind of on hold until Walter fixes IFTI bugs for D1, because Andrei started going wild with APIs that require being able to IFTI remaining parameters when the first few are explicitly specified.

Example from memory:  all the nifty sorting functions require a string parameter for the "a<b" predicate part, but in D2 can infer the rest of the template arguments.  In D1 if you specify any template parameter it instantly stops trying to deduce anything.

--bb

Janice Caron wrote:
> On 10/05/2008, Sean Kelly <sean@invisibleduck.org> wrote:
>>> That is an entirely separate subject. There is a proposal on the table
>>  > suggested by Steven Schveighoffer and myself which addresses that very
>>  > problem, and our proposal sounds similar to your romaybe. However,
>>  > that is not relevant for std.string.
>>
>> It's relevant in that the implementation of std.string could benefit from
>>  the proposal, were it implemented.
> 
> Not so. The invariant versions will use copy-on-write. That is a huge,
> huge, plus for invariant strings, and no one wants to lose it. At the
> other end of the spectrum, mutable char arrays offer the possibility
> of modify-in-place, which invariant clearly cannot do. There is no way
> that Steven's/my inout proposal would be sufficient to achieve all
> that is needed for std.string.

I remember Walter saying that he was surprised at how many string operations did not actually involve in-place modification, and I took this as an explanation for why std.string is designed the way it is. The problem with std.string is that one cannot use it with mutable strings /at all/, and Steven's proposal would change this quite naturally.


Sean