View the error "side effect" as first class.

[waalge]

For example using an if else block to check a few conditions with expects requires a return even if none is needed.
Type checker says.

Diagnostics:
1. I found a discarded expression not bound to a variable.
    [aiken::check::implicit_discard]
2. A function can contain a sequence of expressions. However, any expression but the last one must be assigned to a variable using the let keyword. If you really wish to discard an expression that is unused, you can assign it to '_'. [aiken::check::implicit_discard]

If there is a return statement then let me know I don't use it. If it's void, then check the code concludes with expect statements and assume I know what i'm doing.

I think I don't keep too much company in thinking that "pretend validators are boolean functions" was/is a mistake.
Validators can fail fast. I don't need to and a bunch of conditions if I already found a failure.
It leads to:

• more noisy code
• something akin to jsons issue with trailing commas on the last line of an object.

[KtorZ]

I am not sure to understand your issue? Is it that you want to use "expect" as the last expression in a block? In which case, this is indeed not allowed as expect is fundamentally a let-binding with extra verifications.

[waalge]

Current pattern:

fn do_checks_abc (a, b, c) {
  expect a > 0 
  expect (b / a) > f(c) 
  {{ ... etc ... }}  
  True 
 }  
 
 fn do_all_checks () {
   expect do_checks_abc(a,b,c) 
   expect do_checks_def(d,e,f) 
   {{... etc ...}} 
   True
}

I often do not need a return, but aiken forces me to because... I dunno, I think i should be allowed, if not encouraged, to fail as early as possible

[waalge]

Leaving the last condition to be checked in the caller is just like the trailing comma in json files. Its annoying.
Using and { } blocks ... I just think adds noise. especially when expect statements are colocated with associate logic

[rvcas]

Yea I feel you, we'd need to rethink somethings to make that sort of thing make more sense. I don't know what to do right now but I'll think about some of the compiler internals and see. If we ever move tests to this kind of pattern then that should give us some insight.

[rvcas]

I understand the sentiment. I kinda want to rework tests specifically to only operate with expect.