Patrik Rak:
> On 15.11.2010 21:32, Wietse Venema wrote:
>
> > - The [n,m] and [n..m] notation is not familiar, but the "," and
> > ".." are clear. It is unlikely to confuse people with false
> > expectations when they are familiar with other systems (except
> > mathematicians).
> >
> > - The {n,m} and {n..m} notation handicaps some BASH users with
> > false expectations because Postfix behavior is not identical to
> > BASH behavior. It also conflicts with pattern matching, where
> > {n,m} is used as a quantifier.
> >
> > - The (n,m) and (n..m) notation is familiar to Perl users, and
> > does not handicap them with false expectations. (though it
> > is non-intuitive from a mathematician's point of view).
> >
> > I'm inclined to go for "clarity": [n,m] and [n..m]. With this
> > choice, no-one suffers from false expectations. Anyone can understand
> > that "n,m" means a sequence of n and m, and anyone can understand
> > that "n..m" means a range from n to m.
>
> Well, in this regard, both [n,m] and [n..m] are pretty familiar to Ruby
> users, but I guess those are smart enough to figure it out. :)
>
> Visually, I like the [] the most of the three and {} the least. So if
> the {} wouldn't match the already existing syntax entirely, let's go
> with either [] or ().
Thinking of the longer term, does the preference change when we
take IPv6 into account?
Some Postfix contexts require that IPv6 addresses be enclosed in
[] to avoid confusion with "maptype:mapname" syntax (for example,
static:mapname can have arbitrary syntax in the "mapname" part).
For example, mynetworks would use:
168.100.189.0/28
168.100.189.[0..15]
[2001:240:587::]/64
[2001:240:587::[0..ff]:[0..ff]:[0..ff]:[0..ff]]/64
versus:
168.100.189.0/28
168.100.189.(0..15)
[2001:240:587::]/64
[2001:240:587::(0..ff):(0..ff):(0..ff):(0..ff)]/64
If static: is the only real problem with IPv6 versus lookup table
ambiguity, then perhaps there is a way to make the [] optional
around the IPv6 address, everywhere.
Wietse
