Transience of .front in input vs. forward ranges

[deadalnix]

Le 01/11/2012 05:30, H. S. Teoh a écrit :
> On Thu, Nov 01, 2012 at 12:05:18AM +0100, deadalnix wrote:
>> Le 31/10/2012 18:19, H. S. Teoh a écrit :
> [...]
>>> Actually, there is another problem: many algorithms' output will be
>>> transient or not depending on the input range. For example, we could
>>> write map to use the transient version of byLine, say, but then the
>>> range that map returns will also be transient (no longer safe).
>>>
>>> IOW, transience of .front is transitive in some cases. This again
>>> makes things complicated: as soon as you use a single transient
>>> range, it makes downstream ranges transient as well. So we're back to
>>> the problem of how to mark the range as transient in a transparent
>>> way. :-(
>>>
>>
>> No it isn't always transitive. But that is true that it is in some
>> cases.
>>
>> This is why the code should default to the safe behavior. It is up to
>> the programmer to ensure correctness when opting for an alternate
>> behavior.
>
> But then can the alternate behaviour be used at all? For example, joiner
> will return a range which will be transient if the original range is
> transient. But since this is "unsafe" behaviour, joiner's implementation
> can't take advantage of the faster behaviour at all, since otherwise the
> user, not knowing that it is switching to, say, byLine.fast instead of
> the safe version of byLine, may assume that the resulting range is
> non-transient, but it is actually transient.
>
> So this nullifies the usefulness of having .fast, since many Phobos
> algorithms that would have been able to take advantage of .fast can't,
> because their result will be unsafe. In which case, is it even worth the
> bother to implement such a thing?
>
> I think we still haven't addressed the fundamental issue, that is, we
> need a way to differentiate between transient and non-transient .front
> values. Being able to work with transient values is the best, because it
> automatically also works for non-transient values, but some algos need
> to be able to assume non-transience. This core problem is still
> unsolved.
>
>

Would joiner be able to take advantage of this if it was known or not ?