Pre-RFC: usagetimes (partial mutability)

So, in recent topic, I wrote, that I develop my idea about how we can achieve partial mutability, here is results:

Here I want to gather some opinion about draft document, resolve some related question, gather more critic and, maybe, try to push this to rust rfc repository.

I've worked on this for a while and it's not perfect, but in general I think all is good. Maybe, proposed syntax is not that you expected, but I hope that you will not hate this, at least.

If you interested in, please, read, ask about it, critic it, or guide me through some edge cases. Thanks for attention

P.S. Okay, maybe I'm worried to much, sorry

UPD: Changes moved to branch usagetimes of fork


Is there a reason for lifetime syntax to be written &`a instead of &'a? (with backtick rather than single quote)

edit: just noticed that `a isn't a lifetime but an usagetime specificier. That's wayyy too subtle. Anyway, maybe combine both in an example? (would it be, like, &'a `b X?)

I glad that you notice the difference. Usagetimes and lifetimes are orthogonal features that doesn't affect each other.

I can add examples with lifetimes (I will thinking about this), but the thing is partial mutability must work in the same was as borrowing does. Value \ field cannot be used, when it (or parent) doesn't live long enough.

So, it's trivial, I guess. Thank you for reading

This seems like a feature that won't be used as often as normal lifetimes, so I'd rather not spend one of few remaining free characters we have on it.

Can we use a keyword instead?

struct Point<usage'x, usage'y, usage'color> {
    x: usage'x f64,
    y: usage'y f64,
    // 8u - alpha, 8u - red, 8u - green, 8u - blue
    c: usage'color u32

It's also not clear too me why they should be in the generic parameter brackets <> instead of somewhere else.

1 Like

I like this idea if nothing more than ' and ` are so close to looking the same. To save a few key strokes I suggest: use'

1 Like

I think we must not to mix lifetimes and usagetimes. In my keyboard this can be done with one key (above [tab], left to [1]), so I disagree here.

We can, but this is much verbose. You should notice, that lifetimes recommended to have length as less as possible, in contrast to usagetimes that stands for meaning. They don't positional based.

If we talking about your example, do we need ' symbol?

struct Point<usage x, usage y, usage color> {
    x: usage x f64,
    y: usage y f64,
    c: usage color u32

Or we can try this...

struct Point<usage (x, y, color)> {
    x: usage x f64,
    y: usage y f64,
    c: usage color u32

I don't see the difference.

Also, I'm not interested in syntax discussion, to be honest. Here I would like to discuss about weak places of my idea. Syntax can be adjusted later (but I'm still ready to discuss this, of course)

In many (most?) European layouts ` is a dead key, so it's annoying to type (for instance on my keyboard it's first shift-[key to the left of backspace] and then space, in order to get it by itself and not as a modifier (grave accent) of another key.


Is this a joke to you? Finnish - Keyboard Layout Info

Or this? Polish (214) - Keyboard Layout Info

To be honest I don't think I've ever seen anybody using a Polish-layout keyboard with a Windows or Linux computer, but I think in many European countries these local layouts are indeed in use.

1 Like

Do you have any idea how keyboard layouts work? The button between tab and esc only gives the backtick in US and UK keyboard layouts (and possibly some others). On my keyboard it gives the section sign ยง.


@jdahlstrom I rely on most common keyboard layouts: Keyboard layout - Wikipedia

That page only list keyboard layouts that differ for the main letter area. There are loads of variants of qwerty that move special symbols around or replace some symbols with extra letters. Consider looking at QWERTY - Wikipedia as well, both under language variants and multi-lingual variants.

Can we not argue about keyboard layouts?


Usability of the feature does matter. It is about syntax, sure. But back tick is plain bad for three reasons:

  • Too similar to ' (visually).
  • Really annoying to type on many keyboards (the world is not US centric).
  • It conflicts with inline code blocks in markdown. Since markdown is used in many places, including rustdoc, this forum, the official mdbook docs etc, that seems pretty important.

It's about personal taste, I think.

  • I chose ` by special, since it similar, but very different, from '
  • We need gather statistic of keyboard usage, I'm from Russia, but I have this key
  • Markdown support double backtricks: `` ` ``

We can try something from this list: @#%^

Nobody have said something about feature itself - this is very sad

P.S. A keyboard can be adjusted for this key if it doesn't exist for some reason

Linking directly to the RFC text would probably help.

Personally I found the RFC rather long and hard to read. I also think not enough consideration is given to what should always be considered as the primary alternative to adding any new feature: doing nothing. Is there perhaps a minimal subset of this idea that could be discussed in isolation? I see 5 places the RFC suggests adding usagetimes should be allowed: structs, traits, enums, trait impls, and function argument types that are references, not to mention what's going on with as and ! and the clever idea of not declaring them when the struct has public fields, which makes a degree of sense but also made some of the examples hard to follow. Imagine a "usagetimes MVP" that just focuses on methods and structs with private fields. Would that be worth implementing even with none of the other stuff (enums, traits etc.)? Or is it all or nothing?

1 Like

The feature itself is honestly very very important and, since it was covered multiple times in Niko Matsakis' blog [*], I assumed this would eventually become a RFC; but it appears there's always something else that is more important than making the borrow checker more expressive in this way.

[*] Well at least one time, in 2021, View types for Rust. Here the syntax is &{field} T. (You're right the specifics of the syntax is unimportant at this stage), but I remember this has been covered before. Well in 2018 there was After NLL: Interprocedural conflicts which sketches the problem.

I also want to link to this issue Partial borrowing (for fun and profit) which also features another syntax,

pub fn x_mut<'a>(&mut self)
    -> &'a f64
    where 'a: &mut self.x
    &mut self.x

This can be done with regions or patterns in methods (mentioned by dlight and in my rfc).

Of course, we can shrink this feature, but I think it will not worth to be implemented in that way

Regardless of the keyboard layout, the backtick character should be forbidden to be used in any language at this point. Like it or not, but Markdown has won and is used everywhere, and any inline code snippet which uses it inside is going to be a pain to escape.

We actually even have a precedent here, the Nickel language used to use them for a short period of time, before switching away. Have a look how horrible writing documentation was before: `` `"tag with space" `` โ†’ `'"tag with space"`


This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.