How is chunkBy supposed to behave on copy

Steven Schveighoffer schveiguy at gmail.com
Mon Mar 23 18:51:24 UTC 2020


On 3/23/20 2:15 PM, Jonathan M Davis wrote:
> On Sunday, March 22, 2020 9:43:45 AM MDT H. S. Teoh via Digitalmars-d wrote:
>> On Fri, Mar 20, 2020 at 05:50:26PM -0600, Jonathan M Davis via
>> Digitalmars-d wrote: [...]
>>
>>> And exactly what should happen with basic input ranges is not clear,
>>> because while ideally, you'd just require that they have full-on
>>> reference semantics, that tends to mean that you're forcing them to be
>>> allocated on the heap, which isn't really the sort of thing that we
>>> want to force if we can avoid it.
>>
>> [...]
>>
>> You could just have input ranges be a struct with the copy ctor
>> @disable'd, perhaps?
> 
> A range that can't be copied is useless. It won't even work with foreach,
> because anything you iterate over with foreach is copied when it's passed to
> foreach.

foreach(x; uncopyableRange.move)

foreach(x; ucr.refCounted)

foreach(x; returnsRvalue())

Not only that, but once you define "non-copyable" as a thing for ranges, 
then you can handle this without having to always tack-on ".move" or 
whatnot.

It would be possible. It wouldn't be as "pretty". But most ranges are at 
least forward ranges, so it wouldn't be a terrible problem.

-Steve


More information about the Digitalmars-d mailing list