From 8c759852128ef79a67a39c722631b43f610505aa Mon Sep 17 00:00:00 2001 From: Glen Whitney Date: Fri, 7 Mar 2025 00:37:34 +0000 Subject: [PATCH] Update Other --- Other.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/Other.md b/Other.md index 19b1d5d..b0c9227 100644 --- a/Other.md +++ b/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` 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::() {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?