(It may be the case that these things absolutely cannot be handled in a systematic way in a no-GC/no-runtime language, but I'd really like to see some evidence that this is the case.)
I can only think of one redundant feature, and that is the ? operator. This is because `try!` gets used very often in in a lot of code.
I can only think of one syntactic feature (redundant or otherwise) that doesn't get used often and that is HRTB(`for<'a>`), which needs to be there to be able to specify some types correctly (but is very rare).
In this sense, ? is following in a long tradition.
By special-casing now, one almost-certainly[1] closes the opportunity for future consolidation.
[1] I say almost because it's not necessarily a done deal, but migration gets exponentially harder the longer a language has been "out in the wild". GHC/Haskell has gone through a similar upheaval in the last 1-2 years and it wasn't pretty... but ultimately it seems to at least have survived, so there's that.
>
> closes the opportunity
The door isn't closed for this, `?` works with a "carrier" trait, which lets you extend the operator. Now, it's currently unstable, so right now you can't use it, but the door is wide open for the design of `Carrier` to be finalized.
This was explicitly discussed and thought out before ? was stabilized. It's just that ? was stabilized before Carrier.
The compiler knows nothing about `Result`. There are very few structs that it knows anything about, and these all have to do with atomics or `UnsafeCell` or other intrinsic-based primitives that you don't need to reimplement out-of-tree anyway. It knows a few traits, like Add and Copy and Carrier, which can be used to extend operators and stuff.
Oh, OK that at least sound like sound "defensive design" -- good to hear :). However, what happens if `Carrier` needs to be radically redesigned, e.g. to account for HKTs or Rank-N types (or something similarly 'crazy').
Rust will certainly have warts. Maybe someday in the future we'll feel like this is one of them, maybe not. :)
True, and I think I acknowledged as much in my original comment.
> And people need to reduce their error-handling boilerplate today.
Indeed, I'm just (vaguely) worried about Rust being painted into a corner. As I said in my OP, it may actually be an unavoidable corner -- I hope not, but as you say... I guess we'll see :).
https://en.wikipedia.org/wiki/Safe_navigation_operator
To the contrary of what you're suggesting, I think Rust has done a great job eliminating a lot of the previous special-cased syntax and rebuilding things upon a simplified set of core primitives.
What worries you about it? What things need to be "handled in a systematic way"? Are you just generally opposed to any new syntax in languages or something?