-
Notifications
You must be signed in to change notification settings - Fork 37
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bring types result/error to Spicy and flesh them out further #90
Labels
Comments
changed title from {-Review usage of |
rsmmr
added a commit
that referenced
this issue
Jun 10, 2024
The `result` and `error` types were already implemented internally HILTI-side, but not yet available to Spicy users. Example usage, with draft/proposed syntax: ``` function foo() : result<int64> { ... if ( everything_is_ok ) return 42; else return error"Something went wrong."; } if ( local x = foo() ) print "result: %s " % *x; else print "error: %s " % x.error(); ``` The main catch is syntax: `result` and `error` are pretty common words, so making them keywords is a bit risky in terms of backwards compatibility. However, `result` is probably a bit less common than `error`, so the proposal is this: - `result<T>` becomes the new type for wrapping a value of type `T` or an error value, with `result` becoming a full keyword (i.e., can't be used elsewhere). - `error"MSG"` becomes the constructor for an `error` value with the given message. However, `error` does not become a keyword, and we don't provide a way to refer to the `error` type directly (e.g., you can't write `local x : error;` An alternative would be renaming the types (e.g., `expected` instead of `result`; `error_value` instead of `error`), but not convinced that's better. TODO: - Finalize docs once we have settled on syntax. Closes #90. Closes #1733.
mmguero
added a commit
to mmguero-dev/icsnpp-synchrophasor
that referenced
this issue
Aug 6, 2024
…esultRec to fix syntax error ('syntax error, unexpected RESULT, expecting identifier or scoped identifier')
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Spicy doesn't have the
result
anderror
types yet that HILTI offers. Need to bring them to Spicy, and also review how/if the runtime library for both HILTI and Spicy uses them currently for return values from functions and methods. Generally, the goal is to useresult
wherever reasonable for signaling an error. It should be preferred over exceptions where possible; and also over plain boolean signaling just success/failure (can useresult<void>
for that).The text was updated successfully, but these errors were encountered: