On 3/29/23 09:27, Salih Dincer wrote:
> In this way,
> it could also be used directly with slices. For example:
> auto put(R)(R[] range, R[] source)
> => putImpl(range, source);
That's for rvalues.
> auto put(R)(ref R[] range, R[] source)
> => putImpl(range, source);
That's for lvalues.
If you are proposing keeping the current ref-taking Phobos put() as
well, then the following call would be ambiguous:
slice.put([2]); // Compilation ERROR
That can be remedied by using template constraints for 'slices' vs.
other output ranges. But that would be against the idea of "D slices are
most capable ranges". What I mean is, I should be able to write any
range algorithm and pass a slice to it and it should work. If we go with
your proposal, then we would have to check for that case for some
algorithms like put().
Further, I think the user of put() in templates would have to check
whether they are dealing with a slice or not:
void foo(R)(R range) {
range.put(/* ... */);
// If we go with your proposal, whether 'range' changed depends
// on whether R is a slice or not. Do we have to check with
// 'static if' in such range algorithms?
}
Note that I am not defending the behavior of put(). I am just trying to
explain why it is so.
Ali
