Is std.string by any chance going to see any ripple effects from ranges?  I want to write some patches to make it work with CTFE, which would be useful for some compile time mixin generation, but I don't want to waste time working on a module that Andrei is going to completely revamp anyway.

dsimcha wrote:
> Is std.string by any chance going to see any ripple effects from ranges?  I
> want to write some patches to make it work with CTFE, which would be useful
> for some compile time mixin generation, but I don't want to waste time working
> on a module that Andrei is going to completely revamp anyway.

Yes, std.string must be revamped too. You may want to hold onto your work for a little while more.

Andrei

Andrei Alexandrescu wrote:
> dsimcha wrote:
>> Is std.string by any chance going to see any ripple effects from ranges?  I
>> want to write some patches to make it work with CTFE, which would be useful
>> for some compile time mixin generation, but I don't want to waste time working
>> on a module that Andrei is going to completely revamp anyway.
> 
> Yes, std.string must be revamped too. You may want to hold onto your work for a little while more.

Then I suppose the next question should be:
will a char[] be a range of char, or a range of dchar? (Let's keep wchar out of it)

On the one hand, char is the logical option since that's what the array actually contains. Also, this better allows for mutability (since encoding dchars can lead to not having enough space to store replacements in the current position).

On the other hand, dchars would probably be more useful in many situations.

Maybe an adapter could be written, taking a char[] (or any range of chars/wchars) and acting as a range of dchars?
Perhaps also similar adapters to convert to chars and wchars?

Frits van Bommel wrote:
> Andrei Alexandrescu wrote:
>> dsimcha wrote:
>>> Is std.string by any chance going to see any ripple effects from ranges?  I
>>> want to write some patches to make it work with CTFE, which would be useful
>>> for some compile time mixin generation, but I don't want to waste time working
>>> on a module that Andrei is going to completely revamp anyway.
>>
>> Yes, std.string must be revamped too. You may want to hold onto your work for a little while more.
> 
> Then I suppose the next question should be:
> will a char[] be a range of char, or a range of dchar? (Let's keep wchar out of it)

Glad you asked. Given type C[] in { char[], wchar[], dchar[] }, here are the ranges that can be used to iterate them:

a) byCharacter: a bidirectional range with immutable elements. The element type is always dchar, and the range goes over the full characters in the string. If C == dchar, the range has random access.

b) byCharacterWritable: a more expensive bidirectional range that still has element type dchar but holds a reference to the original string such that it can go back and change it. (This is tricky because writing back a dchar into the string may change its length.) The language needs the alias this feature and solid proxy objects to be able to implement this. If C == dchar, the range has random access and fast writes.

c) byNaturalWidth: a random-access range that iterates the raw elements.

> On the one hand, char is the logical option since that's what the array actually contains. Also, this better allows for mutability (since encoding dchars can lead to not having enough space to store replacements in the current position).
> 
> On the other hand, dchars would probably be more useful in many situations.
> 
> Maybe an adapter could be written, taking a char[] (or any range of chars/wchars) and acting as a range of dchars?
> Perhaps also similar adapters to convert to chars and wchars?

Quite so. The important things are (1) only bidirectional, not random, access is affordable when reading one dchar at a time from char[] or wchar[]; (b) proxy objects are important in assuring proper mutability.


Andrei