http://d.puremagic.com/issues/show_bug.cgi?id=8061
monarchdo...@gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |monarchdo...@gmail.com --- Comment #8 from monarchdo...@gmail.com 2012-12-20 09:08:37 PST --- (In reply to comment #6) > std.range.FrontTransversal and std.range.Transversal also suffer from this > wrong assumption. In this case, [Front]Transversal never actually iterate nor mutates the underlying ranges, so I'd say the save is valid. As a matter of fact, I'd argue that while the argument "name" is RoR, the actual iteration scheme is "Range of stuff that happens to be ranges": Eg: While it is a RoR, the *iteration* scheme stops at R. The underlying ranges are just elements. The only way for save to not work in this situation is outside modification but: a) This is true for ALL wrappers ranges anyways b) Given the "Range of stuff" vision, you can view the underlying ranges as elements whose modifications *should* be visible, even after a save. That said, you bring a valid point, and I think _all_ RoR interfaces should be reviewed. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------