xxxInPlace or xxxCopy?

[Jonathan M Davis]

On Friday, January 21, 2011 12:48:57 spir wrote:
> On 01/21/2011 09:21 PM, Jonathan M Davis wrote:
> > The issue is when you don't look at the documentation or trying to avoid
> > having to look at the documentation. If you see
> > 
> > auto result = replace(str, "hello", "goodbye");
> > 
> > it's quite clear that a copy is taking place. And if a copy/slice is
> > taking place, then that is what you would normally see when replace is
> > used. However, if replace alters the array in place, then
> > 
> > replace(str, "hello", "goodbye");
> > 
> > would be what you would normally see. And without looking at the
> > documentation, it's not clear whether that is doing it in-place or if
> > you're throwing away the return value. However, in the case where
> > replace does a copy/slice, it_is_ clear, because the return value is
> > saved.
> 
> I don't follow you here. You use in your reasoning the particularity of
> C-like funcs which can be both proper functions and action routines.
> Indeed, as you say, one can throw away a result after calling a routine
> which is mainly a function, but for a side-effect; right. But the same
> applies conversely: one can well call a routine which is mainly an
> action (in this case, that operates in-place) and returns whatever
> outcome flag, so that:
> 	auto result = replace(str, "hello", "goodbye");
> actually operates in-place. Which is consistent with its name, an action
> verb suggesting an action. Replace could eg return the number of
> replacements performed (actually useful, what do you think?) Without
> more information, and guessing from the name, that is precisely what I
> would think (and try to imagine what meta-info replace returns).
> 
> Do not misinterpret: I actually support the choice of making return/copy
> the default (where both would make sense), because it's safer. But since
> we are changing many names, why not avoid misleading ones, precisely for
> the default case?

Sure, you can always come up with more exotic stuff that the return value could 
do, but I would expect that your average programmer would think that

auto result = replace(str, "hello", "goodbye");

made a copy of the string with "hello" having been replaced with "goodbye" in 
the return value rather than in-place. Stuff like returning the number of 
replacements made is less typical, and I wouldn't expect that to be what a 
programmer would initially expect the function to do. Obviously, you're going to 
have to look at the documentation to be sure regardless of what the function 
actually does, but in this case, the obvious answer would be the correct one.

I really don't find having functions returning results without altering their 
arguments as the normal case to be odd at all, let alone misleading, since 
that's what most functions actually do. True, it becomes more ambiguous once 
you're dealing with reference types like arrays, and ultimately, you have to 
read the documentation to be sure, but the most typical case is for a function 
to take in a set of arguments and return a result without altering those 
arguments. I see no reason to change that just because you're dealing with a 
reference type. I find replace to be perfectly clear as it is.

- Jonathan M Davis