On Oct 18, 2013, at 11:14 AM, Daniel Micay <danielmi...@gmail.com> wrote:
> On Fri, Oct 18, 2013 at 12:09 PM, Jack Moffitt <j...@metajack.im> wrote:
> In the latest Rust upgrade for Servo, I noticed that the path API is
> now mutate-in-place instead of return a new path. It used to be that
> path.push("foo") gave you a new path with an extra component, but now
> path.push("foo") returns () and mutates the path in place.
>
> I liked the old API better. I realize this is probably more consistent
> with std::vec, and consistency is good. I thought I'd bring this up to
> see what other people thought as a lot of the APIs are getting
> rewritten lately and I haven't seen any concrete guidelines on what
> they should be.
>
> If we decide that both API styles are good to have, what should the
> naming convention be for the functional vs. mutable ones? Ruby,
> Scheme, and Clojure use `!` to denote the in-place mutation ones, but
> that syntax is for macros in rust.
>
> jack.
>
> I think an immutable version should only be exposed if it's as efficient as
> operating in-place. For containers, I really don't want to have APIs that
> exist only to make allocating a whole new container and copying over more
> convenient. It's harder to write efficient code when inefficient code looks
> more idiomatic.
I agree wholeheartedly with this. Path needed to preserve the convenient
“functional update” methods, because creating new paths based on existing
immutable ones is rather common. But the APIs are definitely not more
convenient than the mutation ones, just as convenient.
Regarding Jeff’s suggestion for a mut_ prefix, that really only makes sense to
me when returning some form of &mut value. Although that would typically be
.as_mut_foo() rather than .mut_foo(). In general, I think method names should
make it reasonably obvious whether it’s mutating or not without having to use
“mut_”. In the case of Path, the name .push() has a long history of mutating
the receiver, so Path.push() mutates.
-Kevin_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
