On Friday, 30 August 2013 at 15:16:15 UTC, Dmitry Olshansky wrote:
I think the problem is "put" overstepping its boundaries. If
"r.put(someSlice)" compiles, "put" has no reason to think that
R
actually owns the elements in the slice.
It should and this is where we differ I guess. I can't think of
a useful output range that stores away aliases to slices it
takes.
Not "aliases to slices", but slices themselves. For example, a
dictionary, which is a container of "words" (strings) could
define a sink that accepts strings to feed it word. Or, well
anything that defines the *element* itself as the object. For
example, something that accumulates *lists* of ints.
In any case, I get your point about functionality. I can rework
my pull to make it work as before, while still keeping the
trans-coding functionality :/
But I'm not a huge fan.
