Clarify that removing language features requires an RFC

[brson]

This is a small addition to RFC 1 stating that removing language features, even those behind a feature gate, requires an RFC.

[lilyball]

👍

[pnkfelix]

So, just to play devil's advocate here: can we freely change the semantics of features behind a feature gate without an RFC, as long as we do not remove the feature itself?

(But then what does that mean -- in the limit, freely changing the semantics is not terribly different from removing the feature.)

[lilyball]

People who use feature gates are opting in to the higher risk of their code needing to be modified to continue compiling. Normally modifications to feature gates don't remove functionality, though, just change it. If I'm relying on a feature gate to implement something and it's changed, I can just fix my code. But if the feature gate is removed entirely without warning, then I may be left without a way to fix my program.

The RFC process seems like a reasonable way for people to provide evidence as to why the feature gate is in fact useful, if it's up for deletion.

[bstrie]

+1.

@pnkfelix, it is expected that you should act in good faith when changing the semantics of a gated feature. Making a feature useless for its intended use case should be considered tantamount to removal, and thus requires an RFC. If all you're doing is "improving" the feature, then it's expected that you've done research on how best to improve it, which implies that you've studied the use cases of that feature in the wild. If your improvements would completely invalidate those use cases and offer users no recourse, then you need an RFC.

[brendanzab]

👍

[zwarich]

@bstrie, what if there are no use cases of that feature in the wild?

[lucy]

@zwarich, the RFC would be required to make sure that is the case.

[bstrie]

Well it's not possible to exhaustively search all Rust code in existence, but due diligence is expected. First and foremost, figure out who committed or requested that feature in the first place and ask them if your improvement would invalidate their use case, or if they know of others from using that feature. Even in rare cases where the contributor themselves is not someone you can get in contact with, you can absolutely contact the person who gave the r+ to largely the same effect. If you can't seem to find anyone using that feature, and take that as evidence that you can destroy it without an RFC, then mention that fact in the commit message. When someone later comes out of the woodwork and says hey, I was using that, then keep them in mind the next time that you make an improvement on that feature. If they particularly value the feature that you've destroyed, ask them to make a post to the mailing list stating their case, or submit a pull request of their own that fixes it to their liking.

Really though, how often do you change a gated feature so significantly that it becomes completely intractable for its former use case, without any possible workaround? And how hard is it to just make a dang RFC if you're not sure? :P

[pcwalton]

@lucy The threshold for removing a feature is not "nobody is using it". The threshold isn't even "most people think it should be kept". It's "it's causing more maintenance burden than it justifies".

This is how all open source projects work; it's nothing new. They have to work this way, lest they end up as the union of all features and collapse under their own weight.

[bstrie]

@pcwalton, the comment from @lucy was not implying that a feature cannot be removed as long as even a single person is using it. I'm in the dark as to where you came up with that interpretation.

[lilyball]

The problem with "more maintenance burden than its worth" is the definition of how much a feature is worth. To some people, a feature may be completely useless, while to others the same feature may be critical.

This is why requiring an RFC before removing the feature is important. It allows the chance for people who rely on the feature to make their case and demonstrate why it's worth keeping in the language. It also allows for a chance to come up with an alternative that may satisfy the use-cases of the people who rely on the feature, while reducing the maintenance burden of the feature as it exists in its current form.

[alexchandel]

So can we re-add f128, since it was summarily removed without RFC?

[steveklabnik]

This RFC happened after that, and given that f128 was actually causing problems, I don't think that's appropriate.

[thestinger]

No problems were mentioned in the meeting or brought up in the pull request removing it. What were these problems it was supposedly causing?

[steveklabnik]

@thestinger there were problems, our notes were just poor: http://www.reddit.com/r/rust/comments/290qns/support_for_quadruple_precision_float_point/cigryts

[bstrie]

So can we re-add f128, since it was summarily removed without RFC?

This RFC does not apply retroactively to the removal of f128. However, I would welcome such an RFC as a show of good faith from the developers.

This RFC happened after that, and given that f128 was actually causing problems, I don't think that's appropriate.

I do not dispute that the developers had good reason for its removal. Nobody is suggesting that the developers remove features via random die roll. However, like all language features, its inclusion or omission is a tradeoff. The decision to bypass the RFC process in this case means that we have neglected to adequately consider the technical implications of f128's removal, possibly to Rust's detriment. If this were not a big deal, then this very RFC would not have surfaced. There remains discussion to be had over solving the problems that were encountered, and the reasons for its removal need to be advertised somewhere more public than buried in a reddit thread. I suggest either an RFC or, failing that, a mailing list thread.

Here, though, is not the place to have that conversation.

[alexcrichton]

This was discussed in yesterday's meeting where it was decided to be merged.