Update Other
parent
b583ed1d19
commit
8c75985212
1 changed files with 4 additions and 0 deletions
4
Other.md
4
Other.md
|
@ -3,6 +3,10 @@ Let's suppose you want to increment `x` if `right` is true and decrement it othe
|
|||
|
||||
In the Husht examples, the only in-line two-way conditionals that come up would render this as `x += if right then 1 else -1` or (inherited from Rust) `x += if right {1} else {-1}`. Both of these have a lot of syntax for the semantic payoff. Is there a need for a more compact inline choice for a binary? There is a [stackOverflow answer](https://stackoverflow.com/a/73965190) on this topic that suggests adding an `IfElse` trait to the boolean type so that you can write `(a < b).ifelse(1, -1)`. So in Husht we could take this just a step further (and in a nod to C) allow `x += right.? 1, -1` and `a < b .? 1, -1`.
|
||||
|
||||
### truthy/falsy values
|
||||
|
||||
Currently, even if a type `T` has an implementation of the `Into<bool>` trait -- i.e., a well-defined way to convert itself into a boolean function -- and `t` is an instance of `T`, you cannot write `if t {do_something()}`; you must write something like `if t.into::<bool>() {do_something()}`. [This Rust discussion](https://internals.rust-lang.org/t/use-into-bool-in-if-expressions-if-type-is-not-bool/5919) proposes allowing the former. Husht might well want to adopt such a convention.
|
||||
|
||||
### Mandatory return types
|
||||
A function `fn myconst() -> u32 { 12u32 }` must declare its return type even though it's crushingly obvious from the return value. This is actually not DRY. Should we work to remove this requirement and allow return types to be elided when they can be deduced from the function definition?
|
||||
|
||||
|
|
Loading…
Add table
Reference in a new issue