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.

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

On 4/23/15 5:52 AM, Steven Schveighoffer wrote:
> I'd really like to hear from Andrei on this.

Such an abstraction (a range without the ability to copy its front) is a bit of a rarity so only a small subset of algorithms would work with it. So probably it deserves its name e.g. SingleReadRange. -- Andrei