On Fri, Apr 29, 2016 at 02:36:55PM +0200, Ladislav Lhotka wrote:
>
> > On 29 Apr 2016, at 14:30, Juergen Schoenwaelder
> > <j.schoenwael...@jacobs-university.de> wrote:
> >
> > On Fri, Apr 29, 2016 at 02:19:08PM +0200, Ladislav Lhotka wrote:
> >>
> >> The problem here is that enum statements aren't really restrictions but
> >> rather specify the new set of values. It would be kind of discontinuos:
> >> with
> >>
> >> typedef bar {
> >> type foo {
> >> enum one;
> >> enum two;
> >> }
> >> }
> >>
> >> the "bar" set would be {one, two}. If I remove the "enum two;" statement,
> >> the set would be just {one}, but then if I remove the "enum one;"
> >> statement, the set would again become {one, two}.
> >>
> >
> > So what? Apparently, being able to use foo without having to repeat
> > all values of foo is the main reason to define foo in the first place.
>
> So what about this:
>
> typedef bar {
> type foo {
> enum one {
> if-feature fancy;
> }
> }
> }
>
> If "fancy" feature is supported then the "bar" set is {one}. But if it isn't
> supported, then what?
>
If the "fancy" feature is not set, the value set of "bar" is {} (since
there is a restriction reducing the value set to an empty set).
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103 <http://www.jacobs-university.de/>
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
