My main concern is with new syntaxes. Expanding use-cases for existing ones, loosening restrictions that can be safely loosened, etc. are all well and good. But layering on new sugar-syntaxes that aren't truly necessary makes the language much harder to mentally grok over time. All of a sudden you can't just derive what's happening by studying the code, you have to add new pieces of arbitrary information to your mental toolbelt first. The Ok(..) one mentioned, from a quick glance, seems really unnecessary.
Your general concern, which is that "new syntax makes things less explicit, and is therefore bad", isn't logical.
Adding new syntax has many costs (not only one), but it can also have benefits (hence why it is being proposed), and the real question is whether the benefits outweigh the costs.
That is, whether it is a trade-off worth making.
In the blog post, the author quantify the actual costs of not having Ok-wrapping on their own code, as well as the costs of adding Ok-wrapping to the language, and for them, their numbers suggest that the trade-off is worth it - so they went on and implement it as a proc macro, and are using it on their own code. They don't care whether anybody elses uses it, and they don't have to.
You could have disagreed with their quantification, maybe you have different numbers, and that leads to a different outcome of whether the trade-off is worth making or not.
Instead, you just disagree, without making an argument, and others are doing the same.
In my eyes, this kind of hurts your position, since it gives me the impression that those against Ok-wrapping can't really argue why. Whether they just can't argue in general, lack data to back their arguments up, or maybe even whether they are Rust users at all, is anybody's guess.
I can't imagine a Rust application writer that is using Result idiomatically and not doing _a lot_ of manual Ok-wrapping all over the place. I can't imagine anybody actually enjoying that manual Ok wrapping. Looking at servo, the Rust compiler, and all my applications, what people end up doing is writing their own one-shot local macros to hide that manual Ok wrapping. Having written some of these myself, it definitely did not happen because I was "enjoying it too much". On the contrary, once or twice per function is ok, but when I had to do it dozens of times per function, it was just too painful both for the people writing it and those maintaining that code.
it doesn't seem to me that your reading of brundolf's post is very generous. the post doesn't mention explicitness at all, but says that increasing the number of syntaxes that can be used for the same purpose increases mental overhead for reading code. also, the post says that this particular proposal "seems really unnecessary," strongly implying that the author does not believe the tradeoff is worth it.
personally, while I can't claim to love writing Ok around return values, I definitely value the enhanced readability that comes with it. rust is the most readable language I've ever coded in, and it's not even close. when I see the "throws" syntax that was proposed, I expect it would make it harder to read the code because the Result type is erased from the type signature. To me, whatever tradeoff I would gain in ease of writing code from this would be far outweighed by the cost in reading that code.
C# became that way to me. Some of the new syntactic sugar was redundant and wound up making code less easy to follow. I didn't adopt it all myself, but it made me less interested in parsing through others' codebases.
I still typically remove the LINQ defines from my own new code, and that seems to be one of the more acclaimed language features.
