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
