redefining "put" and "OutputRange"

[Dmitry Olshansky]

30-Aug-2013 21:20, monarch_dodra пишет:
> 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.

The interesting observation is that one can safely alias string or for 
that matter any immutable slices. However any such activity with mutable 
slices is prone to some funky issues, continuing my point that int[][] 
is bad output range :)

> Or, well anything that
> defines the *element* itself as the object. For example, something that
> accumulates *lists* of ints.

Correcting myself - anyway it should deal with potential _mutable_ 
aliasing if it is to keep them around for some reason. If the output 
range can just use it in place - fine.


> 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.

Me neither.

-- 
Dmitry Olshansky