3 ms·

Notes: > value = fn1() error { return } Allow for Error short circuits. This has slowing been adopted by other languages - An error can be handled/or not and

Notes: > value = fn1() error { return } Allow for Error short circuits. This has slowing been adopted by other languages - An error can be handled/or not and continue cleanly without crashing anything (erlang style) or typed semantics (Java style). Go can return an error message, as part of the multi-return semantics, similarly allowing for error short circuits. Because of Bolin's multiple return semantics, you can implement this pattern as well, but it's nice to not bake it in. The for-loop conditional exit handlers are novel enough. Some unique syntax choices, like .= for assign and mutable/immutable assignment dynamically is great. Ponylang has typed containers that act similarly, but they are not dynamically declared. I know I've seen lazy type signatures before, but I don't remember where. So I'd consider it novel enough to note: ie you don't need to specify int every param -> add(int a, b) and implicit void on main() I can't speak to under-the-hood compiler optimizations, but there's a little bit here and there that's interesting. P.S. Typo in: https://bolinlang.com/quickstart/basics https://bolinlang.com/quickstart/basics //you don't need to specificy int every param

levodelellis 4y ago
> Allow for Error short circuits Is the `try` keyword in the highlight section what you're looking for? You can write `var = try fn()` Thanks. I fixed the typo when I first saw this hours ago but it's been busy and I forgot to reply
- Supermancho 4y ago
  > Is the `try` keyword in the highlight section what you're looking for? I worded it poorly. > Allow for Error short circuits I was trying to say that I liked the feature as-is, because it Allows for Error short circuits. There are a lot of common patterns that modern languages avoid idiomatically, despite their widespread use in roundabout ways.
  - levodelellis 4y ago
    I'm not good with this site. Do most people have some kind of notification when someone replies to them? Is the problem with short circuits that you can ignore the error? It's not documented yet but `error return` requires the function to be an error type so the error can propagate. If thats not good enough do you have some insight on how to fix it? What's worse and was designed intentionally by me is `fn() error { return }` not requiring the function to have an error return (although this would be a void return type). I make the assumption if you have a block (instead of `error return`) you're handling the error. You can also propagate by doing something like this `nonErrVal = fn() error { print("write a better error log"); return error }`.

levodelellis 4y ago

> Allow for Error short circuits Is the `try` keyword in the highlight section what you're looking for? You can write `var = try fn()` Thanks. I fixed the typo when I first saw this hours ago but it's been busy and I forgot to reply

Supermancho 4y ago
> Is the `try` keyword in the highlight section what you're looking for? I worded it poorly. > Allow for Error short circuits I was trying to say that I liked the feature as-is, because it Allows for Error short circuits. There are a lot of common patterns that modern languages avoid idiomatically, despite their widespread use in roundabout ways.
- levodelellis 4y ago
  I'm not good with this site. Do most people have some kind of notification when someone replies to them? Is the problem with short circuits that you can ignore the error? It's not documented yet but `error return` requires the function to be an error type so the error can propagate. If thats not good enough do you have some insight on how to fix it? What's worse and was designed intentionally by me is `fn() error { return }` not requiring the function to have an error return (although this would be a void return type). I make the assumption if you have a block (instead of `error return`) you're handling the error. You can also propagate by doing something like this `nonErrVal = fn() error { print("write a better error log"); return error }`.