diff --git a/Block-Results.md b/Block-Results.md
index a2c3497..dfd9aa1 100644
--- a/Block-Results.md
+++ b/Block-Results.md
@@ -1,5 +1,7 @@
 In Rust, a block that ends with a semicolon evaluates to `()`, and a block that doesn't end with a semicolon evaluates to the value of its last expression. In Husht, we want semicolons to be unnecessary, so how do we make this distinction? Here are some ideas.
 
+_Glen added a proposal at the bottom_
+
 ### Explicitly mark results
 
 To indicate that a block evaluates to its last expression, you mark the last expression with a special token. This inverts the Rust convention, in the sense that you indicate a block result by the presence of a token rather than the absence of one.
@@ -99,4 +101,10 @@ Cons
   let x_sq = x*x;
   ```
   
-  gives the error "`if` and `else` have incompatible types" error. Allowing implicit coercion to `()` might mean we instead get the error "cannot multiply `()` by `()`" in the expression `x*x`, making it harder to figure out what and where the problem is.
\ No newline at end of file
+  gives the error "`if` and `else` have incompatible types" error. Allowing implicit coercion to `()` might mean we instead get the error "cannot multiply `()` by `()`" in the expression `x*x`, making it harder to figure out what and where the problem is.
+
+### Glen's proposal
+
+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.
\ No newline at end of file