VLERange: a range in between BidirectionalRange and RandomAccessRange

[Andrei Alexandrescu]

On 1/18/11 7:48 PM, Steven Wawryk wrote:
> On 19/01/11 11:37, Andrei Alexandrescu wrote:
>> On 1/18/11 6:00 PM, Steven Wawryk wrote:
>>> 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.
>
> Ok, thanks for this suggestion. But if developing a proposal as concrete
> code is a lot of work that may be rejected, is there a way to sound out
> the idea first before deciding to commit to developing it?

This is the best place as far as I know.

>> 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?
>
> No, this was just a summary. Here is the post that you answered
> dismissively: news://news.digitalmars.com:119/ih030g$1ok1$1@digitalmars.com

My response of Sun, 16 Jan 2011 20:58:43 -0600 was a fair attempt at a 
response. If you found that dismissive, I'd be hard pressed to improve 
it. To quote myself:

> I believe the proposed scheme:
>
> 1. Changes the language in a major way;
>
> 2. Is highly disruptive;
>
> 3. Improves the status quo in only minor ways.
>
> I'd be much more willing to improve things by e.g. defining the representation() function I talked about a bit ago, and other less disruptive additions.

That took into consideration your amendments.

>  >
>  > In the interest of moving this on, would it become acceptable to you if:
>  >
>  > 1. indexing and slicing of the code-point range were removed?
>  > 2. any additional ranges are exposed to the user according to decisions
>  > made about graphemes, etc?
>  > 3. other constructive criticisms were accommodated?
>  >
>  > Steve
>  >
>  >
>  > On 15/01/11 03:33, Andrei Alexandrescu wrote:
>  >> On 1/14/11 5:06 AM, Steven Schveighoffer wrote:
>  >>> I respectfully disagree. A stream built on fixed-sized units, but with
>  >>> variable length elements, where you can determine the start of an
>  >>> element in O(1) time given a random index absolutely provides
>  >>> random-access. It just doesn't provide length.
>  >>
>  >> I equally respectfully disagree. I think random access is defined as
>  >> accessing the ith element in O(1) time. That's not the case here.
>  >>
>  >> Andrei
>  >
>
>
>> 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.
>
> Sorry, I could have given more context. But you didn't discuss what I
> asked, based on the observation that your detailed criticisms of Steve's
> proposal all related to a single aspect of it.

I really don't know what to add to make my answer more meaningful.


Andrei