While I'm unfortunately not in support of this PR (so far) I'd like to point out that I find it very well thought-through and written. Great work, @withoutboats!
Same here. Thanks indeed, @chriskrycho and @H2CO3.
To give some real-life example for why hiding Option/Result behind syntactic sugar might be a bad idea for the sake of flattening the learning curve.
I have stopped counting the number of intermediate level Swift developers who managed to get used to optional unwrapping à la …
if let foo = bar { // foo: T; bar: Optional<T>
// …
}
… but fail to grasp the whole concept behind enums and the case let syntax …
if case let .some(foo) = bar { // foo: T; bar: Optional<T>
// …
}
For them these are completely disjoint concepts. Telling them that those two things are the same and showing them the source code for enum Optional<T> { … } never fails to blow their minds. (I consider this a bad thing. Their response should be a bored "Well, of course." instead, at this point in their education.)
One might argue that thanks to syntactic sugar they managed to get rather far with Swift without having to understand enums at all. I would argue though that by lifting Optional and the like into a bazillion of syntactic sugars the language actually makes it extremely hard to make the jump from a dev who merely manages to make their code work, to one who actually understands it. This can also be seen in the under-utilization of if case let (generalized pattern matching syntax) in Swift.
Having short-hand syntactic sugar T? for Optional<T> further enforces this misunderstanding of what an Optional actually is. Coming from C++ or Java, most people still think of T? being a nullable pointer-thingy.
I would consider -> T catch E similar in nature to what T? is to Optional<T> in Swift, in that they give the wrong impression that it's something special and completely unrelated to enum.
I dislike T? and if let in Swift for the very same reason that I'd rather not see any exception-like syntax in Rust:
They give a completely wrong picture of how the language actually works, that's damn hard to get rid of afterwards. I've been mentoring lots of Swift beginners and this is a constant struggle. There is a strong and negative sentiment in larger parts of the Swift community (mostly new folks) against having to explicitly unwrap Optional<T>, rather than just accessing the wrapped value as is common in Objective-C, C++, Java and the like. It comes from the wrong impression of T? being little more than an annoying nullable object reference [sic!]. None of this kind of sentiment is found in Rust afaict. Why? Because there is no wrong picture of something being drawn in the minds of the users that is to be annoyed about.
So while one manages to lead beginners to a rather advanced point of their learning curve without having to dive into enum and their peculiarities, one makes them internalize a wrong picture of how the language works, which then later on requires them to unlearn and doubt basically all the things (maybe it's syntactic sugar all the way down and nothing is what it seems?) they just managed to learn so far.
As it happens I have written a lengthy article on why I consider Swift's generous use of syntactic sugar a hindrance, rather than a help for beginners: "Syntactic Diabetes" and a rather heavy burden on the language. I'd rather not see Rust go the same path for the whole sake of instant gratification.