Use the right slash. Fixes #853 #857
Conversation
| @@ -2698,7 +2698,7 @@ dimensions of a [=client window=]. | |||
|
|
|||
| browser.SetClientWindowStateParameters = { | |||
| clientWindow: browser.ClientWindow, | |||
| browser.ClientWindowNamedState // browser.ClientWindowRectState | |||
| browser.ClientWindowNamedState / browser.ClientWindowRectState | |||
There was a problem hiding this comment.
| browser.ClientWindowNamedState / browser.ClientWindowRectState | |
| (browser.ClientWindowNamedState // browser.ClientWindowRectState) |
(seeing the failing tests) should not it be the following? since / for choosing between types and // for choosing between groups?
There was a problem hiding this comment.
Hm. I could be misreading the RFC, but as far as I can tell the only difference between / and // is the early- vs late-binding behavior; otherwise groups are types, right? Like, you'd only use // specifically to deal with groups, to avoid having to use / with parens around the groups.
I see the parse failure, but I'm not certain that's not a bug in the parser you're using. (But I might be wrong.)
There was a problem hiding this comment.
The CDDL parser I wrote currently accepts the construct with a /. The grammar allows that and, as @tabatkins, I didn't see what prevented it in the RFC. Re-reading the RFC, I see that the Operator precedence section says:
Type operators (such as "/" for type choice) operate on types, while group operators (such as "//" for group choice) operate on groups.Types can simply be used in groups, but groups need to be bracketed (as arrays or maps) to become types.
I don't really understand why that's needed, but that seems to say that browser.ClientWindowNamedState and browser.ClientWindowRectState, defined as groups, cannot be used directly in a "/" construct.
Fixes #853.
Preview | Diff