Update Other

Glen Whitney 2025-03-07 00:37:34 +00:00
parent b583ed1d19
commit 8c75985212

@ -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?