• Nick Sabalausky (16/16) Sep 05 2014 One issue with struct-based input ranges: Saving the state of an input
• monarch_dodra (18/35) Sep 05 2014 Ref semantics is one option, yes. Either by class, or by struct.
• Nick Sabalausky (3/10) Sep 05 2014 I see. Good points, thanks.

Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:

One issue with struct-based input ranges: Saving the state of an input 
range is not supported (by definition of input range), and yet, you can 
trivially and accidentally do so with a simple assignment or passing 
into a function. The results may or may not blow up depending on the 
exact situation.

And if the input range happens to hit a poorly-implemented algorithm 
which *should* be statically requiring a ForwardRange and using 
".save()" to duplicate state, but instead accepts any range and 
(accidentally?) saves state by simple struct copy...which will work fine 
for most struct-based forward ranges and therefore could go completely 
unnoticed...Then once again, your input range touches it and BOOM.

This *could* be addressed by making the input range a class, but that 
seems a bit overkill in many cases.

So I'm tempted to give my struct-bassed input ranges a  disable'd 
postblit. That would solve the problem, right? Would there be any reason 
NOT to do this?

"monarch_dodra" <monarchdodra gmail.com> writes:

On Friday, 5 September 2014 at 19:55:50 UTC, Nick Sabalausky 
wrote:
 One issue with struct-based input ranges: Saving the state of 
 an input range is not supported (by definition of input range), 
 and yet, you can trivially and accidentally do so with a simple 
 assignment or passing into a function. The results may or may 
 not blow up depending on the exact situation.

 And if the input range happens to hit a poorly-implemented 
 algorithm which *should* be statically requiring a ForwardRange 
 and using ".save()" to duplicate state, but instead accepts any 
 range and (accidentally?) saves state by simple struct 
 copy...which will work fine for most struct-based forward 
 ranges and therefore could go completely unnoticed...Then once 
 again, your input range touches it and BOOM.

 This *could* be addressed by making the input range a class, 
 but that seems a bit overkill in many cases.

 So I'm tempted to give my struct-bassed input ranges a 
  disable'd postblit. That would solve the problem, right? Would 
 there be any reason NOT to do this?

Ref semantics is one option, yes. Either by class, or by struct. 
For example, most IO ranges implemented ref-counted reference 
semantics.

IMO, disabling postblit is overkill, as almost anything that does 
anything with ranges will pass them by value at one point or 
another.

That said, most of the functions that do operate (and modify) a 
range either take it by reference, or return the modified copy. 
This means you can "boomrang" your range in and then back out. EG:
r = doIt(r);

For example, copy, find etc... do this.

*Ideally*, these functions would do a move-return, and you'd 
pass-by-move, so you'd be able to effectively disable postblit, 
but still pass by move-value. Unfortunately, we aren't quite 
there yet...

My 0.02$

Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:

On 9/5/2014 6:14 PM, monarch_dodra wrote:
 Ref semantics is one option, yes. Either by class, or by struct. For
 example, most IO ranges implemented ref-counted reference semantics.

 IMO, disabling postblit is overkill, as almost anything that does
 anything with ranges will pass them by value at one point or another.

[...]
 *Ideally*, these functions would do a move-return, and you'd
 pass-by-move, so you'd be able to effectively disable postblit, but
 still pass by move-value. Unfortunately, we aren't quite there yet...

I see. Good points, thanks.