aiken/crates/aiken-lang/src/ast
KtorZ efeda9a998
Prevent non-default fallback on exhaustive validator
Technically, we always need a fallback just because the way the UPLC
  is going to work. The last case in the handler pattern matching is
  always going to be else ...

  We could optimize that away and when the validator is exhaustive, make
  the last handler the fallback. Yet, it's really a micro optimization
  that saves us one extra if/else. So the sake of getting things
  working, we always assume that there's a fallback but, with the extra
  condition that when the validator is exhaustive (i.e. there's a
  handler covering all purposes), the fallback HAS TO BE the default
  fallback (i.e. (_) => fail).

  This allows us to gracefully format it out, and also raise an error in
  case where there's an extraneous custom fallback.
2024-08-27 20:16:45 +02:00
..
well_known.rs Prevent non-default fallback on exhaustive validator 2024-08-27 20:16:45 +02:00