Rust Keyword Generics Progress Report: February 2023 [LWN.net]

Rust Keyword Generics Progress Report: February 2023

Posted Feb 25, 2023 21:37 UTC (Sat) by NYKevin (subscriber, #129325)
In reply to: Rust Keyword Generics Progress Report: February 2023 by xi0n
Parent article: Rust Keyword Generics Progress Report: February 2023

I think the argument against this is some variation of "mut is syntactic salt."

In other words:

* Immutable (shared) references have weaker constraints than mutable (exclusive) references.
* If we implicitly promote a reference to mut, then we impose stronger constraints on your program, which may not be obvious from the call-site.
* Those additional constraints may prove difficult to explain in compile errors, since you may not realize which of your references are mut. The compiler would have to explain how it monomorphized all potentially relevant &?mut annotations, and there might be a lot of them (e.g. "Z is mutable, but you borrow it again over here. Z is mutable because Y is mutable, and Y is mutable because X is mutable, and...").
* More generally, taking &mut everywhere is probably a Bad Idea in the first place (for the same reason that const-correctness is so important in C++).
* Therefore, we don't want to hand you a mutable reference unless you explicitly ask for one.
* The easiest way to accomplish that is to have two methods with different names. Inventing exceptional syntax for an operation that would still require the call-site to manually select a specialization would be pointless.

But I don't work on Rust, so the above is just my best guess.

to post comments

Rust Keyword Generics Progress Report: February 2023

Posted Feb 26, 2023 11:19 UTC (Sun) by mb (subscriber, #50428) [Link] (1 responses)

> The easiest way to accomplish that is to have two methods with different names

Yes. I completely agree. We must have separate functions that the caller explicitly chooses from, for mutability.

But I sometimes wish there would be some help from the language to make implementing these functions easier.
For example for simple reference-getter functions we basically just duplicate the function (with added mut).

I'd sometimes like to have something like this:

fn get{_ref|_mut}(& ?mut self) -> & ?mut Foo {
& ?mut self.foo
}

It would still generate two functions with two names, but I would only have to write one.
Yes, I can do that with macros, but support from the language in the form of syntactic sugar would feel much nicer to me.

Rust Keyword Generics Progress Report: February 2023

Posted Feb 28, 2023 16:24 UTC (Tue) by plietar (subscriber, #110706) [Link]

The Pony language has some version of this called "viewpoint adaptation": https://tutorial.ponylang.io/reference-capabilities/arrow-types.html. A function signature can look like "fun get(): this->Foo", which means it returns a Foo "as seen by this": the returned reference is mutable only if the method is called on a mutable receiver.