In my opinion, there are two main reasons why one would prefer an immutable
API over a mutable one: aliasing and sharing substructures. Given that
unique pointers and references have mostly solved the first one, in my
opinion we should prefer mutable APIs unless the API is going to take
advantage of structure sharing. I don't think it makes a lot of sense to
have immutable APIs like this:
fn frob(&mut self) { ... }
fn frobed(&self) -> Frob { let x = self.clone(); x.frob(); x }
It's a lot more straightforward for the users to write `let y = x.clone();
y.frob();`, and it protects us from another combinatorial explosion of
methods.
All that being said, I feel there is an open question on whether or not to
prefer statement oriented mutable APIs (methods like `fn frob(&mut self)`)
and chain-oriented APIs (methods like `fn frob(self) -> Frob`). Does anyone
have a good argument for one over the other?
On Sat, Oct 19, 2013 at 9:42 AM, Eric Sampson <eric.samp...@gmail.com>wrote:
>
> Date: Fri, 18 Oct 2013 10:54:23 -0700
>> From: Jeff Petkau <j...@google.com>
>>
>>
>>
>>
>> On my code (disclaimer: only toy projects to learn Rust so far), I've
>> been
>> pretty happy with a "mut_" prefix for mutable versions.
>>
>> newthing = oldthing.push(foo")
>> anything.mut_push(foo")
>>
>> x = bagofun.sort()
>> bagosadness.mut_sort()
>>
>> etc.
>>
>> Advantages:
>> - consistent meaning with the 'mut' keyword.
>> - works with pretty much any name.
>> - makes mutable versions just a bit uglier than immutable code.
>>
>> Disadvantages:
>> - If an API is inherently mutable, it gets pretty noisy.
>> - A bit ugly, probably turns off newcomers.
>> - If the compiler warns on ignoring return values, and mutating methods
>> return (), then a convention might be unnecessary.
>>
>> --Jeff
>>
>>
> What about establishing a convention that mutable methods start with an
> uppercase letter while non-mutating methods start with a lowercase letter?
> It would be lightweight in terms of character count/looks and at the same
> time give mutable methods a slight visual emphasis, which makes sense I
> think.
>
> I know this convention is already used by Traits, but when I looked
> through some code with the above proposal in mind it would be easy to
> distinguish between these two uses of the same convention due to the
> differing contexts they're used in.
>
> -Eric
>
>
>
>
>
>
> _______________________________________________
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
>
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
