support size of list or dict using ()

[stdweird]

E.g.

type x = string[](1..2);

should be a list of strings with at least one and max 2 elements.

Should also allow

type x = string(5..10)[](1..2);

so list with 1 or 2 strings with length between 5 and 10

and also dict(2..4)[](5..6){}(8..9)
etc etc

[ned21]

The first example looks OK but the second starts to look a bit complicated. I don't understand what the last one does! (List with 5 or 6 elements that must be dicts... wait: dict[]{} isn't valid PAN today?!)

The use case seems valid but it we need to avoid confusing/ambiguous syntax, e.g.

type x = string[] with length(SELF) > 0 && length(SELF) < 3;

Does that apply to the length of the list of the length of the string within a list? Using brackets before & after the [] is actually less ambiguous but it's hard to remember: which is the length of the string and which is the length of the list?

How about:

type x = string[1,2] with [ length(SELF) > 0 && length(SELF) < 3 ];

The [1,2] constrains the length of the list and then the use of [] instead of {} shows it's a list comprehension on each member? My feeling is that being able to generically apply functions to members of a list via list comprehension syntax is more useful than being able to just constrain the length of a string.

[stdweird]

@ned21 i like the [1..2] or {1..2} for size of list or dict (but we should use the .. separator imho); but i also like that (1..2) means size of of any type.

so

type x = string[];
type y = x(1..2);

should always be possible. maybe we can promote () to mean size of any type, and allow shortahnd [1..2] to mean [](1..2)?

SELF always means the full type, i don't find that confusing, but i do mind the boilerplate.

dict[]{} is (or should be) valid pan, but my point with the 3rd example was to remind myself to make this fully recursive.

[stdweird]

conclusion was that there is no real strong argument against either one, will have a look what is easiest to implement and come back with a PR