oversight with input ranges

[Steven Schveighoffer via Digitalmars-d]

On 4/23/15 5:03 AM, Dominikus Dittes Scherkl wrote:
> On Wednesday, 22 April 2015 at 19:37:21 UTC, Steven Schveighoffer wrote:
>> Yeah, I like this. But now we have to name the flag :)
>>
>> I don't think it should be a bool, because:
>>
>> isInputRange!(R, true)
>>
>> Is pretty obtuse. I'd rather see something like:
>>
>> isInputRange!(R, RangeOption.NonCopyable)
>>
>> Or whatever name we come up with.
>>
>> The nice thing about this solution is that the range options could be
>> passed down the trait chain, so isForwardRange easily gets this
>> ability as well.
>>
>> -Steve
>
> I don't like that, because this is NOT an input range, it is something
> inferior but it is enough that some algorithms happen to work also on
> this crippled input range. And option would indicate that it has some
> extra features over and above what a general input range provides, which
> is not the case.
> This would require to change the code of every algorithm taking input
> ranges to check if the range is copyable - exactly what we don't wanted!
>
> I would name it clumsy "isNonCopyableInputRange", and change only those
> algorithms that can cope with such a thing.

I've given some more thought to how this is playing out. If you look 
around std.algorithm, etc., you will see many different "additive" 
traits for input ranges, i.e. hasAssignableElements, hasSlicing, all 
these things that work on top of the basic building blocks of ranges to 
further tune what an algorithm can do.

This is kind of a new thing that wasn't considered, and something where 
we can't say "is input range but doesn't have x", because isInputRange 
doesn't provide a less specific version. It's like we thought we had 
discovered the atom, only to find we actually just discovered a molecule.

Note, that the only *language* requirements for ranges is that foreach 
works with them, and foreach works with these. But the library adds this 
requirement that the elements be copyable. I'm actually not convinced 
this was intentional, as when ranges came about, I don't believe we had 
the ability to disable copying.

I begrudgingly agree with you that the flag idea isn't going to cut it.

The alternatives here are, we fix isInputRange so it allows non-copyable 
elements (I don't think we can do this immediately, it's an API change 
to a fundamental building block), or we have a fleet of 
isNonCopyableXRange. That lacks appeal as well, especially in the DRY 
department.

I wonder if a possible fix is to define hasRangeTroika or whatever, and 
then hasCopyableElements, and define isInputRange to mean both. Then 
later we can deprecate the meaning of isInputRange to mean both, and 
just have it mean the first. I don't know of a good way to do this so 
people are warned that their code won't work. The nice thing about 
isInputRange is that it's just a template constraint. If the code 
expects the copyable nature, it would simply mean a compile error in 
compiling the function vs. a compile error in finding a suitable 
template. It might be a distinction without a difference.

I'd really like to hear from Andrei on this.

-Steve