Closed KtorZ closed 1 month ago
But one thing to consider is that Pattern::Var is also a thing.
That's a good point. The current args var do have one extra thing though which is: a label. That's really the only difference between the Pattern::Var
and the current ArgName
. That and how we explicitly distinguish Discarded
for Named
values for ArgName
; which we rely on in a few places. I don't see reasons why it wouldn't work with Pattern::Var
too but that's another layer of changes.
So, definitely a possible refactor, although it's not obvious whether it would actually make a lot of things simpler.
it's not obvious whether it would actually make a lot of things simpler.
indeed :)
:round_pushpin: Introduce 'ArgBy' to allow defining function arg not only by name.
:round_pushpin: Bump 'is_validator_param' up from 'ArgName' to '...Arg' There's no reasons for this to be a property of only ArgName::Named to begin with. And now, with the extra indirection introduced for arg_name, it may leads to subtle issues when patterns args are used in validators.
:round_pushpin: Authorize complete patterns as function args. This is mainly a syntactic trick/sugar, but it's been pretty annoying to me for a while that we can't simply pattern-match/destructure single-variant constructors directly from the args list. A classic example is when writing property tests:
Now can be replaced simply with:
If feels natural, especially coming from the JavaScript, Haskell or Rust worlds and is mostly convenient. Behind the scene, the compiler does nothing more than re-writing the AST as the first form, with pre-generated arg names. Then, we fully rely on the existing type-checking capabilities and thus, works in a seamless way as if we were just pattern matching inline.
Some error examples too: