Hacker News Reader

There is already precedent of somewhat magical syntax changing the return type, namely 'async' making the function return a future<your stated return type>. While this approach adds one more non-obvious thing for a newcomer to learn, it shouldn't make it much more difficult to reason about your code once you know what to expect.

View on HN

I might agree more if async was just doing the Future type wrapping. However, because it is doing much more, it feels fundamentally different (hence the keyword).

I probably haven't interacted enough with larger rust projects, but I just don't see how "OK(123)" could ultimately cause all that much friction when working with the language.

Oh, I'm totally fine with Ok(123). The current syntax with Result is explicit and flexible even if slightly verbose. It's especially nice that Result is an enum like any other.

I don't think async is a good comparison. Compiling async functions is inherently magical, since it involves the compiler mucking with your control flow graph. This makes it less of a surprise when magic shows up in your type signature. On the completely opposite hand, what makes Results cool is that they require no magic beyond enum/match. (Yes, it's nice that there's sugar like '?', but you don't need it to write code that uses Results correctly)

Reply on news.ycombinator.com