Andy Bierman <[email protected]> wrote:
> On Mon, Nov 9, 2015 at 10:38 AM, Martin Bjorklund <[email protected]> wrote:
>
> > Hi,
> >
> > I implemented most of the 1.1 features that affect the compiler in
> > pyang on the flight back from Yokohama. (if you have 1.1 modules, I'd
> > appreciate if you could try it out).
> >
> > In doing this, I realized that I forgot one part of Y10 - "allow
> > restrictions on enumerations". If we allow:
> >
> > typedef foo2 {
> > type enumeration {
> > enum a;
> > enum b;
> > }
> > }
> > typedef bar2 {
> > type foo2 {
> > enum a;
> > }
> > }
> >
> > we should also allow:
> >
> > typedef foo2 {
> > type bits {
> > bit a;
> > bit b;
> > }
> > }
> > typedef bar2 {
> > type foo2 {
> > bit a;
> > }
> > }
> >
> > It is briefly mentioned in the description of Y10.
> >
> >
> > Comments?
> >
> >
> Yet more complexity without any real use-cases?
It is a matter of removing CLRs and inconsistencies.
> How does auto-numbering work in both cases?
>
>
> typedef foo2 {
> type enumeration {
> enum a;
> enum b;
> }
> }
>
> typedef foo3 {
> type foo2 {
> enum b;
> }
> }
>
> typedef bar1 {
> type enumeration {
> enum b;
> }
> }
>
>
> What is the auto-numbering of enum 'b' in type foo3?
There is none. The text says:
When an existing enumeration type is restricted, the "value"
statement MUST either have the same value as in the base type or not
be present, in which case the value is the same as in the base type.
> What value does type foo3 have over bar1?
Unless the type has some semantics, there is none. But when the type
has some semantics, the possibility to restrict an existing type is
useful. If it not useful for enumerations and bits, why should we
have it for strings and ints, for example.
/martin
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
