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
> instead of
> 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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk