Still need syntax (retain ... or switch to *) to bind a name to extras.
Not as safe. The intent behind ... was to require positive affirmation that additional elements are acceptable. This has proven to be a weak argument because forgetting to add ... also causes annoying bugs to surface when additional attributes or keys are introduced.
Proposed strategy
Based on discussion, we'll implement the following stepwise strategy:
[ ] For tuple and dict patterns, remove the error when extra entries are present but ... isn't. Retain it for array patterns. It's less clear that this change is warranted for arrays.
[ ] Add support for * as a synonym for ....
[ ] Add support for ! at the end of a tuple or dict pattern. It will trigger an error when extra entries are present (equivalent to the current behaviour when ... is absent).
[ ] Deprecate ....
[ ] Remove support for ....
For arrays, it's less clear what the right default is. Perhaps there should be no default, and so all array patterns would have to end in either * or !.
Please do not post any internal, closed source snippets on this public issue tracker!
Purpose
...in pattern syntax is a bit verbose at times, e.g. https://github.com/anz-bank/sysl-go/blob/3452b0c2d89fb05d2eb8a89a6365868c58bee69c/codegen/arrai/go.arrai#L22:L22:Consider alternative syntaxes.
Suggested approaches
Alternative 1:
*Pros:
?pattern for arrays ([1, 2, ?, 4, *, 8, 9]). Feels like shell globbing.Cons:
Alternative 2:
!Use
!to fail if additional elements are present.Pros:
Cons:
...or switch to*) to bind a name to extras....was to require positive affirmation that additional elements are acceptable. This has proven to be a weak argument because forgetting to add...also causes annoying bugs to surface when additional attributes or keys are introduced.Proposed strategy
Based on discussion, we'll implement the following stepwise strategy:
...isn't. Retain it for array patterns. It's less clear that this change is warranted for arrays.*as a synonym for....!at the end of a tuple or dict pattern. It will trigger an error when extra entries are present (equivalent to the current behaviour when...is absent).........For arrays, it's less clear what the right default is. Perhaps there should be no default, and so all array patterns would have to end in either
*or!.