Re: [boost] Re: Re: string algorithms review

From: Pavol Droba (droba_at_[hidden])
Date: 2003-10-20 11:50:16

On Mon, Oct 20, 2003 at 06:13:49PM +0300, Peter Dimov wrote:
> Thorsten Ottosen wrote:
> > "Peter Dimov" <pdimov_at_[hidden]> wrote in message
> > news:02a001c39712$16d66260$1d00a8c0_at_pdimov2...
> >> Thorsten Ottosen wrote:
> >>> I and why is it an error? What about this error:
> >>>
> >>> trim( s ); // bug: s is not changed
> >>>
> >>> ?
> >>
> >> <shrug>
> >>
> >> std::sin(x); // bug: x is not changed
> >>
> >> FWIW, I much prefer the functional style in this case.
> >
> > My point was that (most) verbs in the imperative means mutation,
> > nothing else. I expect
> > mutation to happen in those cases. I also expect a function called
> > remove() to mutate the input and
> > I consider a different behavior very strange.
> 
> In this specific case, I don't expect or want mutation by default; strings
> are logically much closer to immutable values than they're to stateful
> objects, and string operations in most languages reflect that.
> 
> Naming aside, a non-void return from inplace mutators is, IMO, a mistake,
> too. There is never a _need_ to chain inplace mutators; you can always write
> 
>     trim_inplace(s);
>     do_something_with(s);
> 
> instead of
> 
>     do_something_with(trim_inplace(s));
> 
> I even find the explicit sequencing preferable, if a bit verbose.

As I see from the discussion, the chaining of mutable variants it not essential. I can accept
this argument. 

So my question is, if the mutating variant would return void, would it be enough to show, that this
particular variant is mutable?

So the convention would be:

- copy variants have suffix _copy
- mutable variants will have no suffix, but will return "void" instead of reference.

Pavol