/// Expect:
/// - output: "PASS\n"
enum Foo {
A
B
}
fn may_throw() throws {}
fn thing() {
let a = match Foo::A {
A => try may_throw() catch {},
B => {}
}
}
fn main() {
thing()
println("PASS")
}
/// Expect:
/// - output: "PASS\n"
enum Foo {
A
B
}
fn may_throw() throws {}
fn is_void() {}
fn thing() {
match Foo::A {
A => try may_throw() catch { yield is_void() },
B => {}
}
}
fn main() {
thing()
println("PASS")
}
Both fail to compile the C++ for a couple of reasons:
try codegen does not use statement-exprs when compiling void, so return <try> and return ExplicitValue(<try>) have statements inside them without having a block to support them.
Optional<void> is used in both C++ outputs, the first one for the a variable, and the second one for the catch result value.
Depending on how we want to handle this, it's either typechecker's fault or codegen's fault:
If we allow void? and void to be unified, then the codegen should handle these cases, maybe it needs to do so explicitly. This would be useful if we want the second sample to typecheck, although that would collide with the current behavior of requiring void match cases to be in non-yielding blocks.
If not, then it's obviously a type mismatch and the typechecker is not handling it correctly. Also, nothing should be assigned void? since that doesn't really make sense in the first place (void? is isomorphic to bool, so why use the former).
Given these two samples:
Both fail to compile the C++ for a couple of reasons:
try
codegen does not use statement-exprs when compiling void, soreturn <try>
andreturn ExplicitValue(<try>)
have statements inside them without having a block to support them.Optional<void>
is used in both C++ outputs, the first one for thea
variable, and the second one for the catch result value.Depending on how we want to handle this, it's either typechecker's fault or codegen's fault:
void?
andvoid
to be unified, then the codegen should handle these cases, maybe it needs to do so explicitly. This would be useful if we want the second sample to typecheck, although that would collide with the current behavior of requiring void match cases to be in non-yielding blocks.void?
since that doesn't really make sense in the first place (void?
is isomorphic tobool
, so why use the former).