<div><div dir="auto">That’s dope homie</div></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 23, 2020 at 2:15 PM Jonathan M Davis via Digitalmars-d <<a href="mailto:digitalmars-d@puremagic.com">digitalmars-d@puremagic.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">On Sunday, March 22, 2020 9:43:45 AM MDT H. S. Teoh via Digitalmars-d wrote:<br>
> On Fri, Mar 20, 2020 at 05:50:26PM -0600, Jonathan M Davis via<br>
> Digitalmars-d wrote: [...]<br>
><br>
> > And exactly what should happen with basic input ranges is not clear,<br>
> > because while ideally, you'd just require that they have full-on<br>
> > reference semantics, that tends to mean that you're forcing them to be<br>
> > allocated on the heap, which isn't really the sort of thing that we<br>
> > want to force if we can avoid it.<br>
><br>
> [...]<br>
><br>
> You could just have input ranges be a struct with the copy ctor<br>
> @disable'd, perhaps?<br>
<br>
A range that can't be copied is useless. It won't even work with foreach,<br>
because anything you iterate over with foreach is copied when it's passed to<br>
foreach. And of course, idiomatic range code passes ranges all over the<br>
place, resulting in a lot of copying. And to wrap a range in another range<br>
(which is required for most range-based algorithms), you have to copy it.<br>
IMHO, it would make far more sense to just use opApply than to try to make a<br>
range non-copyable.<br>
<br>
- Jonathan M Davis<br>
<br>
<br>
<br>
</blockquote></div></div>