Open dfellis opened 5 months ago
cond
for bool
has been implemented. If both branches are defined they need to both return the same type, if one branch is defined it auto-wraps into a Maybe{T}
for the true branch.
This does make it a good fit for use in assignment statements, and I wonder what, if any, syntactic sugar should exist for that usage.
It wouldn't be too hard to get a ternary-like set of operators, though there would be the unexpected closure function syntax necessary. It would also be possible to add some syntactic sugar, which could work like Rust or Python or do something different entirely.
Removing this from the 0.2 release as the functional if(cond, truePath, falsePath)
works for now, so this is not necessary for the initial release.
The Alan v0.2 conditionals concept is that
if <conditional> { ... } else ...
is rewritten intocond
function calls where all function bodies are branchless and must run until the end.This means
return
statements are only valid as the last statement in a function body at that point.This also means that conditional branches that don't return and pass back control flow to the higher layer must instead bolt on the follow-up code to the tail of their own function body. Excepting only if all branches of a conditional do not return, where fall-through is allowed, and all branches where the conditional does return, in which case follow-on code is a failure.
The
cond
function will be just like any other function, so users can write their own that accepts something other thanbool
s. This will be used for native GPGPU support, as both branches of a conditional need to be transformed into an AST to serialize towgsl
for the GPU.