Transience of .front in input vs. forward ranges

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Sun Nov 4 05:24:55 PST 2012


On 11/3/12 7:21 PM, H. S. Teoh wrote:
> On Fri, Nov 02, 2012 at 04:17:10PM -0400, Jonathan M Davis wrote:
>> On Friday, November 02, 2012 10:01:55 H. S. Teoh wrote:
>>> Ah, I see. That makes sense. So basically it's not the source (or
>>> any intermediate step) that decides whether to use the optimization,
>>> but the final consumer.
>>>
>>> Though now we have the issue that all intermediate ranges must
>>> propagate .fast, which is troublesome if every range has to do it
>>> manually. Can this be handled automatically by UFCS?
>>
>> It's no different form propogating slicing or random access or
>> whatnot. Wrapper ranges have to look at the capabilities of the ranges
>> that they're wrapping and create wrappers for each of the range
>> functions where appropriate. If we added isTransient or fastRange or
>> whatever, wrapper ranges would then have to take it into account, or
>> the wrapper wouldn't have it.
> [...]
>
> I wish Andrei would give some input as to how we should proceed with
> this. I do consider this a major issue with ranges, because for
> efficiency reasons I often write ranges that have transient .front
> values, and they can lead to subtle bugs with the current implementation
> of std.algorithm. It would be good to settle on this issue one way or
> another. I'd be happy even if the decision is to say that transient
> ranges are invalid and shouldn't be considered "real" ranges. Anything
> is better than the current nebulous state of things which only leads to
> subtle bugs for the unwary.

I think at this point we should streamline and simplify ranges while 
addressing fundamental concepts (such as unbuffered ranges). Delving 
into defining increasingly niche attributes for ranges is important 
work, but to the extent we can make things simpler that would be a gain.

In my view, transiency of .front has a lot to do with input ranges. An 
input range means that .front is evanescent upon calling .popBack; it 
has no lasting presence in memory, and invoking popBack means the next 
item will replace the current one.

Fetching lines should be solved by using types; trafficking in char[] 
does not offer guarantees about the preservation of the content. In 
contrast, trafficking in string formalizes a binding agreement between 
the range and its user that the content is immutable.


Andrei


More information about the Digitalmars-d mailing list