Sum up Sep 2 discussion takeaways
parent
9a5dcd3268
commit
d32e4b7e89
@ -107,4 +107,14 @@ Cons
|
|||||||
|
|
||||||
Husht will generally be semicolon free. I feel like most blocks will actually be fine with returning their last expression's value. So could we start with using _exactly_ Rust's convention? In other words, if there is no semicolon on a block's last expression, its value is returned. If there is a semicolon, then its value is dropped/suppressed (whichever it actually is) and the block returns Unit. Since we are not using semicolon for anything else in Husht (except possibly if you for some reason really want two statements on one line), it seems perfectly fine to use it for this. So I propose we start this way -- will clearly be super easy to implement -- and see if there end up being an annoying amount of semicolons that we need to have. My guess is that it will be a reasonably small handful, which will be fine. They do mean something, after all, so they are not WET (write everything twice) -- they carry actual independent information, in that block-final position.
|
Husht will generally be semicolon free. I feel like most blocks will actually be fine with returning their last expression's value. So could we start with using _exactly_ Rust's convention? In other words, if there is no semicolon on a block's last expression, its value is returned. If there is a semicolon, then its value is dropped/suppressed (whichever it actually is) and the block returns Unit. Since we are not using semicolon for anything else in Husht (except possibly if you for some reason really want two statements on one line), it seems perfectly fine to use it for this. So I propose we start this way -- will clearly be super easy to implement -- and see if there end up being an annoying amount of semicolons that we need to have. My guess is that it will be a reasonably small handful, which will be fine. They do mean something, after all, so they are not WET (write everything twice) -- they carry actual independent information, in that block-final position.
|
||||||
|
|
||||||
If it turns out that a clear majority of block-final expressions are needing semicolons and we can't come up with a good, typing-free "80% rule" for when Husht should insert them, we could as you suggest flip the scrip and always insert them, adopting one of your proposed notations for explicitly suppressing them.
|
If it turns out that a clear majority of block-final expressions are needing semicolons and we can't come up with a good, typing-free "80% rule" for when Husht should insert them, we could as you suggest flip the scrip and always insert them, adopting one of your proposed notations for explicitly suppressing them.
|
||||||
|
|
||||||
|
> *This proposal seems similar to what Julia does. A Julia function returns the value of its final expression by default. If you want it to return `nothing`, you have to explicitly end it with the expression `nothing` (or `return nothing`), which I've never done in my own code. (Maybe it's more routine in library code.) —Aaron*
|
||||||
|
|
||||||
|
### Sep 2 discussion takeaways
|
||||||
|
|
||||||
|
During the meeting, we weighed the merits of two approaches:
|
||||||
|
- A block in Husht returns its last statement by default. Some token, like a final semicolon, can be used to suppress the return.
|
||||||
|
- A block in Husht returns `()` by default. Adding some token to the final expression will cause it to be returned.
|
||||||
|
|
||||||
|
Both approaches sometimes require the last statement in a block to include an *extra token*. One advantage of returning `()` by default is that the extra token communicates the author's intent: "I want this value to be returned." When the last statement is returned by default, the extra token communicates something more contingent on implementation details and less related to the author's intent: "This final expression happens to return a value other than `()`, but I don't want that value to be returned."
|
Loading…
Reference in New Issue
Block a user