It might be a question of terminology mostly, but in my mind
* `all` means "every element without exception" (replace with `each`, `every`
?)
* `any` \- at least one, maybe more, test all elements in sequences regardless
* `none` \- none. Inverse with `all`.
* `first` or `find` \- at leas
> but that could be fixed by injecting matches: seq[int] in the scope. Do you
> think it is necessary to do this?
Why a seq? `any` can stop after the first found match.
Currently `any` captures all elements in `@val`, not just first one. I agree
this might be confusing, so maybe renaming it to `findAll` and `find` might be
a good idea.
Indices of matched elements are not accessible in any predicates right now, but
that could be fixed by injecting `matches: seq
Beware of `any`, people will use it and then need to know which element really
did match. And if that's not available they have to use `find` afterwards. And
then we have the typical performance vs convenience tradeoff. But it's a
tradeoff Nim doesn't have to make with its DSL powers.
It is really similar to the python version (e.g. a lot of similar features and
syntax). Sequence pattern matching is more feature-full, with support for
things like `all`/`none`/`any` \- closely matching templates from `sequtils`
module (namely `allIt` and `anyIt`), so you should be able to writ
For the others, the PEP is [this](https://www.python.org/dev/peps/pep-0622/).
Pattern matching is one of my favorite aspects of Elixir. It'd be fantastic
having it in the Nim stdlib :-) Out of curiosity, how would this compare to
that new Python PEP?
Yes. I adapted case object idea from patty and some syntax elements from gara.
ast-pattern-matching only supports nim node matching so it is not really
applicable in general case of pattern matching.
Have you had a look at the syntax proposed by the different [pattern matching
modules](https://github.com/nim-lang/Nim/wiki/Curated-Packages#language)?
I and @alehander42 started working on adding pattern matching in stdlib. Right
now we at ideas brainstorming stage - what is needed, syntax, potential escape
hatches for user-defined behavior etc. There have been some discussion in RFC
on github -
[link](https://github.com/nim-lang/RFCs/issues/
10 matches
Mail list logo
