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