Quick return about bosquelanguage HOT 8 CLOSED

I think Rust's ? operator already is quite general.

Have a look at this compiler error from the documentation:

error[E0277]: the `?` operator can only be used in a function that returns
`Result` or `Option` (or another type that implements `std::ops::Try`)
 --> src/main.rs:4:13
  |
4 |     let f = File::open("hello.txt")?;
  |             ^^^^^^^^^^^^^^^^^^^^^^^^ cannot use the `?` operator in a
  function that returns `()`
  |
  = help: the trait `std::ops::Try` is not implemented for `()`
  = note: required by `std::ops::Try::from_error`

As you can see it not only works for Results but also Options and in fact everything else that implements Try.

from bosquelanguage.

It seems you added optionals, ala Swift to the language.

You could add explicit error processing like:

var res = enter_profile(x, y) else destroy_user()

Or, you could just allow implicit broken chains by passing a failed optional. For example:

var new_user_num = update_profile(edit_profile(user_num))
display_user(new_user_num)

would be equivalent to:

 var temp1, temp2 = undefined, undefined
 if user_num != undefined:
     temp1 = edit_profile(user_num)
     if temp1 != undefined:
         temp2 = update_profile(temp1)
 var new_user_num = temp2 
 if new_user_num != undefined:
     display_new_user(new_user_num)

This quickly implements the "get out of dodge" error handling method without odd syntax.

What language goal are you trying to accomplish?

from bosquelanguage.

For early return on an error and propagating them upwards, I could recommend the rust's shortcut for propagating errors

Is this what you mean?

from bosquelanguage.

Yes, something like that. This type of operator appears in a number of languages. I would like to think about:
Is there a more general form of this operator or is it really better as a very specific operator like in Rust where the function must return a Result type?

from bosquelanguage.

I think we need some kind of a variant which signals errors or no-success, like None, null, Error, Exception etc.
This has the be specified in the language itself.
Or would you like the have some kind of falsy values/variants which all indicate failure? On the other hand, this makes it hard to distinguish between the situation where an error occured and the successfully computed result has simple the value false.

from bosquelanguage.

@bert2 Thanks for that information: Yes the Try trait "defines" the functionality of the ? operator:

A trait for customizing the behavior of the ? operator.
A type implementing Try is one that has a canonical way to view it in terms of a success/failure dichotomy. This trait allows both extracting those success or failure values from an existing instance and creating a new instance from a success or failure value.

from bosquelanguage.

Old, unable to learn

from bosquelanguage.

I like the syntax where one token (?) signifies 'deals with error'. It probably provides a richer experience to use the same token in two contexts:

ship = lookup(number)?.address   // finds number, or *returns* for enclosing function
print_label(ship?)   // is falsey if ship is falsey, otherwise calls print_label()

An alternate to the second form is to declare the function as checking the paramters:

 function print_label(id?: id_type) {}   // automatically returns falsely if id is falsey

I'm using the term falsey, though I expect None or Undefined or Null to be a reserved word. We have all seen JavaScript errors where the undefined was confused with null. I like Python's use of None and False and items that evaluate to boolean(false).

from bosquelanguage.