[bennofs]

Having these "very special features" means that there are some things with are added to the language but rarely used. That means that you might come across code in a library that you don't understand, especially if you're not using those features in your own code.

So, I think the argument that "very special features" shouldn't be counted toward language complexity/growth is wrong, IMO. I would even say that there needs to be even more focus on those features, since they tend to be not widely known, not familar, and often there is less documentation about them, so the likelyhood that they make code hard to understand is even higher.

This is not to say that those features are unnecessary. I just don't think the justification "they are not what a pragmatic programmer will see" is good.

[estebank]

If you look at the changes and cathegorize them they all fall in one if three camps:

- sugar for quality of life improvements that benefits everyone (like ? or NLL)

- new feature that lets you do something that couldn't be done before (like impl Trait or global allocators)

- new feature that removes a special case of the semantics that can be extrapolated from already present features (like associated consts and subslice patterns)

[FreeFull]

I'd say having special features is ok, as long as these criteria are met:

1) It's obvious the feature is being used.

2) The feature is easy to look up without knowing what it's called, just based on how it's been used.

3) It's easy to understand what the feature actually does, with the appropriate context.

[estebank]

The ? operator doesn't fulfill at least two of the three points, yet it's way more loved than hated. As a general guideline I agree with your points, but it is not to be taken as rigid gospel either.