I don’t think we should design mojo around an application which shows a popup when you press a dot.
having this syntax for raising → Result could make using StopIteration for iterators ergonomic enough to use at least.
(from the review comment)
var res: Result[Int, Error] = try some_raising_function()
1 Like
Before we have proper tagged unions, I consider it a waste of developer time and human resources to make premature API decisions like these. With the same ABI, we have three options: ‘Option’, ‘raise(ZST)’ and ‘Result[ZST]’. Now is the time to relax.
I don’t like the idea of overloading “try.” Before adding a lot of complexity to the language, first consider whether such a feature can be implemented in the library.
fn result_adapter[*Args, Ret, Raise](raising: fn(*Args) raises Raise -> Ret) -> fn(*Args) -> Result[Ret, Raise]: ...
EDIT: Of course, the casts are noops at the ABI level. It should be ensured that the function calls, movs, and insertValue and extractValue instructions are completely optimized out at the LLVM IR level, even in debug mode.
It’s a good transition, but I’m concerned that it will cause performance regressions if “has_next” is small and can be inlined easily, but the “next” body is large and cannot be inlined easily, exceeding the inline threshold. Considering modular is calling mojo a “performance-oriented programming language,” I would have at least waited before the mojo compiler supports trivial function outlining.
The Pythonic next(mut self, sentinel: NoneType) -> Optional[Self.Item] is still not supported. If it is added, perfect LLVM IR generation should be ensured, since “Optional[T]” and “raises(StopIteration) T” should have the same ABI.