Tricky semantics of ranges & potentially numerous Phobos bugs

[Andrei Alexandrescu]

On 10/16/12 5:51 PM, deadalnix wrote:
> Le 16/10/2012 21:21, Jonathan M Davis a écrit :
>> On Tuesday, October 16, 2012 12:07:01 H. S. Teoh wrote:
>>> Perhaps mark ranges with an .isTransient property (which can be an enum
>>> so it doesn't waste any space), and range-based functions that require
>>> non-transient ranges will refuse to work with a transient range. Or
>>> alternatively, switch to a different implementation that takes
>>> transience into account (which may be slower, etc., but the important
>>> thing is to do it right -- after all, D's motto is safe by default,
>>> unsafe if you ask for it).
>>
>> Not a bad idea, though it's still arguably a bit disgusting to
>> potentially
>> have to check for that all over the place. Inevitably, most functions
>> won't
>> check, and ByLine _still_ won't work. Yes, Phobos would presumably end up
>> checking in most cases, but I suspect that little else will. We
>> arguably have
>> way to many things to check about ranges as it is. So, I'd be far more
>> tempted
>> to just change ByLine to use opApply rather than adding the extra
>> complication
>> of isTransient to the standard library just for this one use case.
>>
>
> I have to agree here. Even if I see several uses outside byLine, this is
> known that most code will not take that into account. Adding a property
> isn't going to help.

The property is already there - .save. The question boils down to 
whether input ranges should be acceptable as ranges or not.

Andrei