glen/husht
1
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity

Update Other

Glen Whitney 2024-08-26 20:40:56 +00:00
parent 93220029bf
commit 8361e23d0e
1 changed files with 3 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
Other.md

@ -2,3 +2,6 @@
Let's suppose you want to increment `x` if `right` is true and decrement it otherwise. In C you might write `x += right ? 1 : -1;`. Let's suppose you want to increment `x` if `right` is true and decrement it otherwise. In C you might write `x += right ? 1 : -1;`.
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 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`. 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 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`.
### 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?