VLERange: a range in between BidirectionalRange and RandomAccessRange

[Andrei Alexandrescu]

On 1/18/11 6:00 PM, Steven Wawryk wrote:
> On 19/01/11 02:40, Andrei Alexandrescu wrote:
>> On 1/18/11 1:58 AM, Steven Wawryk wrote:
>>> On 18/01/11 16:46, Andrei Alexandrescu wrote:
>>>> On 1/17/11 9:48 PM, Michel Fortin wrote:
>>>>> This makes me think of what I did with my XML parser after you made
>>>>> code
>>>>> points the element type for strings. Basically, the parser now uses
>>>>> 'front' and 'popFront' whenever it needs to get the next code point,
>>>>> but
>>>>> most of the time it uses 'frontUnit' and 'popFrontUnit' instead
>>>>> (which I
>>>>> had to add) when testing for or skipping an ASCII character is
>>>>> sufficient. This way I avoid a lot of unnecessary decoding of code
>>>>> points.
>>>>>
>>>>> For this to work, the same range must let you skip either a unit or a
>>>>> code point. If I were using a separate range with a call to toDchar or
>>>>> toCodeUnit (or toGrapheme if I needed to check graphemes), it wouldn't
>>>>> have helped much because the new range would essentially become a new
>>>>> slice independent of the original, so you can't interleave "I want to
>>>>> advance by one unit" with "I want to advance by one code point".
>>>>>
>>>>> So perhaps the best interface for strings would be to provide multiple
>>>>> range-like interfaces that you can use at the level you want.
>>>>>
>>>>> I'm not sure if this is a good idea, but I thought I should at least
>>>>> share my experience.
>>>>
>>>> Very insightful. Thanks for sharing. Code it up and make a solid
>>>> proposal!
>>>>
>>>> Andrei
>>>
>>> How does this differ from Steve Schveighoffer's string_t, subtract the
>>> indexing and slicing of code-points, plus a bidirectional grapheme
>>> range?
>>
>> There's no string, only range...
>
> Which is exactly what I asked you about. I understand that you must be
> very busy, But how do I get you to look at the actual technical content
> of something? Is there something in the way I phrase thing that you
> dismiss my introductory motivation without looking into the content?
>
> I don't mean this as a criticism. I really want to know because I'm
> considering a proposal on a different topic but wasn't sure it's worth
> it as there seems to be a barrier to getting things considered.

One simple fact is that I'm not the only person who needs to look at a 
design. If you want to propose something for inclusion in Phobos, please 
put the code in good shape, document it properly, and make a submission 
in this newsgroup following the Boost model. I get one vote and everyone 
else gets a vote.

Looking back at our exchanges in search for a perceived dismissive 
attitude on my part (apologies if it seems that way - it was 
unintentional), I infer your annoyance stems from my answer to this:

>>> How does this differ from Steve Schveighoffer's string_t,
>>> subtract the indexing and slicing of code-points, plus a
>>> bidirectional grapheme range?

I happen to have discussed at length my beef with Steve's proposal. Now 
in one sentence you change the proposed design on the fly without 
fleshing out the consequences, add to it again without substantiation, 
and presumably expect me to come with a salient analysis of the result. 
I don't think it's fair to characterize my answer to that as dismissive, 
nor to pressure me into expanding on it.

Finally, let me say again what I already said for a few times: in order 
to experiment with grapheme-based processing, we need a byGrapheme 
range. There is no need for a new string class. We need a range over the 
existing string types. That would allow us to play with graphemes, 
assess their efficiency and ubiquity, and would ultimately put us in a 
better position when it comes to deciding whether it makes sense to make 
grapheme a character type or the default character type.


Andrei