The in and !in operators?

language design
41

I am opposed to this proposal. My position is that it would be best to add a contains method to the appropriate types and make no other change.

  • The .contains() method already exists on many types. Removing it would be a breaking change, but keeping both it and the in sugar would mean inconsistent APIs.
  • A precedent is set by the community’s reaction to the Unless/Until RFC, which added syntax sugar of a similar level of usefulness (though to be fair part of this criticism was due to the fact that it proposed to add new keywords).
  • Very little is gained from typing y in x rather than x.contains(y). It has been previously mentioned that it obscures a potentially expensive operation; I personally don’t find this argument compelling as it could be made against any overloaded operator. The problem I do have is with the arguments regarding learnability. in is not easier to learn than .contains(). Language learners use the standard library documentation to discover functionality. I would be much more likely to discover Iterator::contains than to guess a piece of syntax. If that were not the case, this Python question would not exist.

I also don’t like the idea of add a Contains trait and turning contains into a trait method, because this requires we add another trait to the prelude. In addition, I don’t see any reason for a function to be generic over Contains that couldn’t be better served simply by taking a closure returning a bool.

4 Likes
42

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