Replace be with become

[ranma42]

Rendered view

[ranma42]

Related to my original question here: #271 (comment)

[bstrie]

+1 to this. Everyone that I've asked about this has preferred become to be, sometimes enormously so. Let's also remember that be was originally chosen by Graydon back when Rust guidelines kept keywords at five characters or less (return was ret in those days).

In terms of keywords to reserve, it also seems more likely that a user would accidentally attempt to use be as a variable name than become.

The remaining objection that I can foresee is whether we want to reserve a keyword at all for this purpose. Given that the TCE proposal has been merely postponed rather than rejected, I am free to conclude that others find this eventual feature as valuable as I do. If we ever ultimately decide against it, we can simply unreserve the keyword.

[steveklabnik]

I like become as well, but I'd be in favor of just reserving both for now, and then we can deal with the question of what to use when the design for TCO actually happens.

[ranma42]

@steveklabnik should I add that to the alternatives section?

[steveklabnik]

Sure :)

[nikomatsakis]

I'm mildly amused by the idea of bikeshedding a reserved word for a non-existent feature, though I think I agree with your suggestion (particularly now that we long ago changed from ret to return). Still, maybe we should just remove both from our list of reserved words, since our general policy has been to assume we will find some way to opt-in for new keywords in the future.

[nikomatsakis]

I guess @bstrie already commented on my point. I can kind of go either way in any case (that is, leave something reserved, or leave nothing reserved). Reserving both feels a bit like overkill. In general we've been moving away from reserving keywords, but this does fall under the category of "clear and desired purpose".

[Valloric]

Reserving become seems like the way to go. If the TCE feature that was proposed ends up being implemented, we would want to have that keyword at least available for consideration. Even in the (remote) case that we pick be then, become can then easily be removed from the keyword list.

So IMO reserving become is not bikeshedding the name as much as delaying the bikeshed (and, sigh, making it possible).

[nikomatsakis]

@Valloric to be clear, no decision that we make here in any way "forecloses" the option of one keyword or the other. Our general position has been that we will not reserve every keyword we think we might want, but rather just adopt a mechanism for adding new keywords backwards compatibly in the future. That said, there are a number of reserved words that were "grandfathered" in---and in some cases, it seems to make sense to keep the word reserved, since we're pretty sure we're going to want it. This might be an example of the latter case.

[ranma42]

@nikomatsakis I prepared a branch which implements the replacement to evaluate the extent of the change (at least in rust-lang/rust; servo/servo should be fine, as it does not use become except in comments; other projects might break). This branch might also be a convenient reference to find out what needs to be done to have both be and become as reserved keywords. If the RFC is accepted, I will update as needed and do the PR.

[nikomatsakis]

@ranma42 if you've done the work to implement it, I'd be inclined to accept this RFC and that PR.

[ranma42]

@nikomatsakis I fixed the conflicts and rebased it: rust-lang/rust#21918. I will file separate pull requests for the editor syntax files.

[ranma42]

@nikomatsakis ping?

[nikomatsakis]

We've decided to accept this RFC. Tracking issue is rust-lang/rust#22141.