RFC: Reserve `delegate` as a keyword in edition 2018

[Centril]

🖼️ Rendered

📝 Summary

The keyword delegate is reserved in edition 2018 and beyond.

🎵 Note

This RFC only aims to reserve delegate for possible future use so that we have options.
For the (current) main delegation proposal, please see #2393.

💳 Credit

All credit goes to the authors of RFC #2393!

[varkor]

Maybe this has been bike-shedded in #2393, but if this is being proposed as a standalone RFC, it's probably worth bringing up here. delegate is quite a long keyword compared to Rust's traditional preference towards more concise names. Is this definitely the right keyword to reserve?

[Centril]

@varkor I agree and share your concern, both on that delegate and is long, and Rust's preference for brevity. However, a briefer word may not have the same fidelity to construct as delegate does. I checked the synonyms of delegate (verb) but none were much good. I believe fidelity is more important than brevity here. But if we can eat our 🎂 and keep it, we should!

The best synonyms I could think of are:

• designate
• confer

but they are not that great.

The longest keyword we have right now is continue (8 letters) which would be as long as delegate so at least it wouldn't be the longest =P

[varkor]

I checked the synonyms of delegate (verb) but none were much good.

One possibility is simply contracting, e.g. deleg.

The longest keyword we have right now is continue.

Yeah, continue is an unfortunate concession to pronunciation. I personally feel we should err towards shorter keywords unless necessary.

[joshtriplett]

This seems reasonable to me.

[Centril]

@varkor Not a fan of deleg, but sure, that's an alternative.

Attempting a semi-rigorous motivation:

We have a few used keywords that are contractions.
I think there are two main groups here:

• Taken directly from C / C++: struct(ure), enum(umeration), const(ant), extern(al)
  For keywords in this group, they work because they are well known from C.
  A keyword such as struct is also so commonly used that it does not need to rely on the word it was based upon any more.
• Not from other languages:
  • fn (function) -- probably the most used keyword in the language, and it is a central concept. As such, it is typed often and needs to be short. It is also taught as the very first concept in Rust.
  • impl(ementation) -- The full word is 14 characters long; so typing it often would become a problem for ergonomics. It is also used very often. In this case, the winning is quite large and so the contraction is well motivated.
  • mod(ule) -- again, used very often.
  • mut(able) -- same here, used often in &mut.
  • pub(lic) -- same.
  • ref(erence) -- it has been used often, but will fade away with default match bindings.

Meanwhile, my prediction is that delegate would not be as commonly used as most of the above keywords (with the exception of ref in the future). Furthermore, you only save ate (3 characters), and so you go from 8 to 5 characters.

In conclusion, it seems to me that the loss to readability is larger than is made up by improved writing ergonomics. Weighing readability vs. writability, I think we should say that writing ergonomics is something like half as important (hard to quantify, but you get the idea?) as readability. Therefore, I think delegate is better than deleg.

[nikomatsakis]

I'm fine with reserving -- my only hesitation, though, is that delegate can be clearly done as a contextual keyword (since it would only appear We did discuss the policy around this, though, and I think we said that we would prefer "true keywords" where possible. In accordance with that, I'm ok with this.

[joshtriplett]

We discussed this in the lang team meeting, and agreed to reserve delegate as a keyword. We're expecting a subsequent RFC to make use of this keyword and define the semantics.

@rfcbot fcp merge

[rfcbot]

Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged teams:

• @aturon
• @cramertj
• @eddyb
• @joshtriplett
• @nikomatsakis
• @nrc
• @pnkfelix
• @scottmcm
• @withoutboats

Concerns:

• value (#2429 (comment))

Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[shepmaster]

delegate is quite a long keyword

I think that's an acceptable tradeoff — the concept of delegation is already about (a type of) compression, so having a slightly longer word is ok to me.

One possible "rescue" is that some potential usage might be closer to how where is used:

impl Foo {
    delegate
        A to b,
        B to c;
}

[nrc]

@rfcbot concern value

I'm unsure of the value of this. Given that delegate is both a common design pattern (from the GoF book) and idiom, I would expect it to be relatively widely used as an identifier. So the cost to reserving it seems high. Given that in we will almost certainly be able to use a contextual keyword, that delegate is not a great keyword because of its length, and that I'm not at all convinced we need delegation in the language, I think this is a pretty low value (reward/risk) reservation.

[Centril]

@nrc

I would expect it to be relatively widely used as an identifier.

Why guess?

is not used as an identifier in the standard library.
is not used as the name of a crate.
is found 19+ times by sourcegraph. The extent of breakage is fairly minimal.

If more data is needed we can reserve the keyword in a PR on edition 2015 and then crater run it.

Given that in we will almost certainly be able to use a contextual keyword

Sure; but a policy was adopted. ;) is this case particular?

I'm not at all convinced we need delegation in the language

This surprises me; I think it is well motivated feature and a problem for many, as evidenced by it being brought up frequently:

• #1406
• #2393
• #2431

[withoutboats]

There's also the fact that making this a keyword requires us to gate any delegation on the 2018 edition. I don't see a reason not to support new features on the old edition unless it makes it substantially more difficult.

delegate is used in a position in which we already have contextual keywords (default comes to mind in particular), and in which the grammar is comparatively simple (not even all items are permitted, much less arbitrary expressions). While the policy outlined was a good rule of thumb, I think this is a clear case in which making it a noncontextual keyword would only have the effect of limiting who can use delegation, without making the implementation any easier.

[shepmaster]

to gate any delegation on the 2018 edition

Does it? Can't it be a contextual keyword in 2015 and enhanced to a full keyword in 2018?

[kennytm]

is found 19+ times by sourcegraph. The extent of breakage is fairly minimal.

The sourcegraph query only search for item declarations, which I don't think is a good metric. You may declare fn delegate(&self) or mod delegate only once, but there could be hundreds of dependencies calling foo.delegate() or use self::delegate.

An upper limit query gives 298/400 search results (including comments and strings), which is far from minimal even if you discount this by 50%.

[Centril]

The sourcegraph query only search for item declarations, which I don't think is a good metric.

I was mostly concerned with breaking public APIs; internal uses should be considered less problematic because it has less of a chain-effect, so it seems to me not a bad metric in that respect.

Here's a query looking for field/self.delegate and ::delegate:
https://sourcegraph.com/search?q=repogroup:crates+case:yes++%5Cb%28%28%5Cw%2B%5C.delegate%29%7C%28%5C:%5C:delegate%29%29%5Cb+max:400+file:%5C.rs

repogroup:crates case:yes  \b((\w+\.delegate)|(\:\:delegate))\b max:400 file:\.rs

[nrc]

I was mostly concerned with breaking public APIs; internal uses should be considered less problematic because it has less of a chain-effect, so it seems to me not a bad metric in that respect.

This is still an element of user pain which we should avoid if possible.

Sure; but a policy was adopted. ;) is this case particular?

aiui, that applies to actual features which are in the process of being designed and implemented, not a general policy that we should reserve every keyword which might someday be useful.

This surprises me; I think it is well motivated feature and a problem for many, as evidenced by it being brought up frequently:

I disagree that it is well-motivated, but even assuming there is good motivation there is no consensus at all on what a solution looks like or even if a solution will require a keyword. There are plenty of features around which have had discussion and a few RFCs, but I don't think we want to reserve keywords for all of them, and I don't see why delegation is special here.

[repax]

To what extent has using existing keywords instead been discussed? I only found these snippets under Alternatives:

A more frugal option to reserving delegate would be to reuse derive for these purposes. However, the keyword fits less well than delegate with respect to the user's intent where delegate fits quite well.

Another option is to simply not use delegate, however, we feel confident that we should keep this option open to us right now. Not doing so would mean that we couldn't use the word delegate as a keyword for another 3 years or so.

Examples off the top of my head:

use self.x as y;

use impl self.x for y;
 
impl y as self.x;

... 

[Ixrec]

In past iterations of delegation proposals, use was explicitly rejected because it would be easily confused with (and would needlessly rule out the possibility of someday supporting) actual use statements that import things inside of an impl block.

But I think that's the only existing keyword that got suggested enough to be properly discussed. afaik delegate and maybe some sigil-based syntaxes are the only real contenders at the moment.

[Centril]

@Ixrec http://hackage.haskell.org/package/base-4.11.1.0/docs/Data-Proxy.html

[Boscop]

@shepmaster People could easily find the meaning of the keyword through google, because the docs about the proxy keyword will have the word "delegation" in the title. This short keyword is in the same vein as the other short keywords that Rust currently has. No one who is new to Rust knows what e.g. impl means (e.g. they could think it's used for Scala-like implicit conversions), but the docs explain it, and they are easy to find with google. Also newbies will have to read the book a couple times anyway, where this will be explained. And no one has complained that the keywords fn, pub, impl etc. are too short or that for short keywords it's not clear to newbies what they mean. Anyone who googles "how to delegate a method to a struct member in Rust" will find the docs site that explains the keyword (no matter which one it will be). But I don't think this counts as an argument against using proxy as the keyword.

Or the other direction: Someone sees the proxy keyword in someone else's Rust code for the first time and then googles "rust proxy keyword" and will also find the docs page that explains it :)

Also the argument that other languages don't use this keyword doesn't really count IMO. Other languages also don't have many of the other keywords that Rust has. And I don't know any languages that use delegate as a keyword either! E.g. the D language uses alias (which is less meaningful than proxy as a keyword (btw, they were re-using this keyword which was already used for other things)).

@Centril I know about the Proxy from PureScript but there is no potential for confusion between that and a proxy keyword in Rust :)

[Centril]

@Boscop

I think Proxy is misleading. A proxy to me is something that stands-in for something, not the something itself. Particularly, in Haskell land, it means the same thing as PhantomData. As @shepmaster put it, the fidelity to construct of delegate is superior. I think delegate * to self.field; is super clear for the person who sees the construct for the first time.

And no one has complained that the keywords fn, pub, impl etc. are too short or that for short keywords it's not clear to newbies what they mean.

I've discussed this here: #2429 (comment)

And I don't know any languages that use delegate as a keyword either!

C# does. https://github.com/Centril/rfcs/blob/rfc/reserve-delegate/text/0000-reserve-delegate.md#prior-art

[Boscop]

@Centril But in C# delegate means something else, so that cancels out the argument that Proxy means something else in Haskell! People are capable of distinguishing different languages :)

Also, please consider my other points I made at the top here (they also apply even if delegate will be used as the keyword).

I think delegation / proxying will be used a lot (at least in my projects) so it should have a shorter keyword. And deleg is short, too, but proxy is equally short, but also a complete word :)

But if we won't end up using proxy as the keyword, I'd vote for deleg instead of delegate. It's easy to guess the meaning even for a newbie reading someone else's code, and also easy to google etc :)

[repax]

Delegation is when you authorise another to serve as your representative for a particular task.

Now consider this statement:

impl TR for S {
    delegate * to self.f;
}

Clearly, f is the proxy or the delegate of S with regards to TR. However, only "delegate" is a verb. If you insist on using "proxy" then you must shift things around:

impl TR for S {
    use self.f as proxy for *;
}

and that's hardly any shorter. And even that doesn't feel quite accurate: proxy for * of TR?

[Boscop]

@repax proxy can also be used as a verb, and has been used as a verb at least sincce 1983:
https://en.wiktionary.org/wiki/proxy#Verb

proxy (third-person singular simple present proxies, present participle proxying, simple past and past participle proxied)

1. To serve as a proxy for.
   1983, Alfred Blumstein, National Research Council (U.S.). Panel on Sentencing Research, Research on Sentencing: The Search for Reform, page 143

   In many of the studies we reviewed, it is common practice to use an observed variable to proxy for a relevant variable that could not be observed.

2. (networking) To function as a server for a client device, but pass on the requests to another server for service.

[Centril]

I googled a bit:

• https://softwareengineering.stackexchange.com/questions/300766/what-is-the-difference-between-proxy-class-and-delegation-in-python
  This suggests proxy is a good word.

However, I think "proxy foo to self's bar" does not sound natural while "delegate foo to self's bar" does.

[joshtriplett]

Per further discussion, the modified keyword policy suggested by @aturon, and agreement from @Centril:
@rfcbot fcp cancel

[rfcbot]

@joshtriplett proposal cancelled.

[joshtriplett]

@rfcbot fcp close

[rfcbot]

Team member @joshtriplett has proposed to close this. The next step is review by the rest of the tagged teams:

• @aturon
• @cramertj
• @eddyb
• @joshtriplett
• @nikomatsakis
• @nrc
• @pnkfelix
• @scottmcm
• @withoutboats

No concerns currently listed.

Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[elahn]

@joshtriplett is the modified keyword policy you're referring to published somewhere?

[joshtriplett]

@elahn #2441 (comment)

[shepmaster]

TL;DR — the policy doesn't really impact delegation as a feature, just whether or not we'd reserve a keyword in the hopes of the feature being implemented.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[rfcbot]

The final comment period, with a disposition to close, as per the review above, is now complete.

By the power vested in me by Rust, I hereby close this RFC.

[Boscop]

@Centril

This suggests proxy is a good word.
However, I think "proxy foo to self's bar" does not sound natural while "delegate foo to self's bar" does.

It doesn't have to be readable verbatim like a grammatically correct English sentence.
The syntax can be chosen freely, as long as it makes sense when reading (after learning Rust / reading the Rust book).
(A lot of existing language constructs can't be read verbatim like an English sentence.)

So could we also reserve proxy as a (contextual) keyword, before making the decision which of the two keywords we end up using? :)
I really think the shorter proxy keyword would be better, because I'm using delegation in my code a lot (currently via a macro crate), and it's more in the spirit of Rust to use short keywords.

[Centril]

@Boscop This RFC is closed now; so I propose we continue the discussion at #2393.