xxxInPlace or xxxCopy?

[Jonathan M Davis]

On Friday, January 21, 2011 12:15:42 spir wrote:
> On 01/21/2011 07:47 PM, so wrote:
> >> replace is clearer in the first case, because you're getting the
> >> return value.
> >> ...
> > 
> > I am really trying hard to understand this, but your reasons for first
> > is clearer then the second makes no sense to me i am sorry.
> > I still think second is clearer, but whatever, as long as i can see the
> > interface or the doc, i am fine.
> > 
> > string replace(string, ...);
> > void replace(ref string, ...);
> > 
> >> Regardless, I don't see anything wrong with naming functions in a
> >> manner that
> >> implies that a functional style is the default
> > 
> > I am not against enforcing such a rule, i am against doing it implicitly
> > and work with assumptions.
> > Just check boost/string/replace, they have in place replaces default
> > too. You might not like boost (some don't) but it is the closest example
> > to D.
> 
> Without any additional information, I would necessirily assume replace
> performs an /action/ because it's an action verb: meaning it changes the
> argument. Like 'so', I cannot understand the converse reasoning.
> I you want people to guess that a true function returns a result, just
> name it according to its result: replacedString, ot just replaced.
> Nobody, I guess, would ever think that a routine called replacedString
> acts in-place.

The fact that a function performs an action has nothing do to with whether it 
alters its arguments or just returns a value. It could be either.

Functional languages _must_ return a result and _can't_ alter their arguments. 
Many, many functions are rewritten that way in pretty much _all_ languages. In 
fact, I'd argue that the _normal_ case is that you pass arguments to a function, 
and it returns a result without altering the arguments. It's only when you get 
into reference types that that changes.

And, of course, arrays are reference types (abeit somewhat special ones). But 
since non-reference type arguments never get altered, and many functions with 
reference type arguments don't alter there arguments (in fact, I'd argue that 
_most_ functions don't alter their arguments - regardless of whether they're 
reference types or not), _not_ altering the arguments would be what you would 
typically expect of a function unless the name made it obvious that that wasn't 
the case, or what the function did made it obvious, or if you read the 
documention and then _knew_ what it did.

And honestly, I find the whole python thing of using the past partiple for 
indicating that the result is returned rather than done in place is just weird. 
I'd expect a function like sorted to give me a boolean result telling me whether 
a range is sorted, _not_ that it would return a sorted version of the range that 
you gave it. I expect function names to be verbs, not past participles. Now, as 
bizarre as that convention may be, it could make functions clearer if you know 
about the convention and it is followed. However, as someone who has never dealt 
with code written that way, reading code that was written that way would be 
rather confusing at first.

In any case, I'd argue that having a function _not_ alter its aruments is the 
typical default case of functions in general, so assuming that a function 
altered in place just because you passed it an array seems odd to me.

- Jonathan M Davis