On Mon, Nov 9, 2015 at 11:40 PM, Martin Bjorklund <[email protected]> wrote:
> Andy Bierman <[email protected]> wrote: > > On Mon, Nov 9, 2015 at 1:11 PM, Martin Bjorklund <[email protected]> wrote: > > > > > 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. > > > > > > > > > > good > > > > Is the refinement allowed to add, remove, or change if-feature-stmts? > > I don't remember seeing any text on that. > > The refine statement cannot address individual enums/bits (it can only > address structure) so the answer is that it is not possible to change > if-feature on enums/bits in refinements. > > It looks like it is -- 9.6.3. Restrictions An enumeration can be restricted with the "enum" (Section 9.6.4) statement. +--------------+---------+-------------+ | substatement | section | cardinality | +--------------+---------+-------------+ | description | 7.21.3 | 0..1 | | if-feature | 7.20.2 | 0..n | | reference | 7.21.4 | 0..1 | | status | 7.21.2 | 0..1 | | value | 9.6.4.2 | 0..1 | +--------------+---------+-------------+ Sec 9.6.3 says any sub-statement of enum-stmt is allowed All of the derived sub-statements from the refined enum are brought over I asume typedef foo4 { enumeration { enum A1 { if-feature foo; } enum A2; } } typedef foo5 { type foo4 { enum A1; } } Is enum A1 conditional on the foo feature in both foo4 and foo5 typedefs? typedef foo6 { type foo4 { enum A2 { if-feature bar; } } According to the spec, adding if-feature in foo6 is also allowed. typedef foo7 { type foo4 { enum A1 { if-feature bar; } } Is the A1 enum in foo7 conditional on feature foo and bar, or just bar? > > > 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. > > > > > > > > > > so the reason to do this would be to restrict the value set but > > maintain the value and position assignments. OK > > > > /martin > Andy
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
