-
-
Notifications
You must be signed in to change notification settings - Fork 34
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clarify that options and attributes are unordered #751
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A couple of comments.
@@ -319,7 +319,7 @@ the following steps are taken: | |||
|
|||
#### Option Resolution | |||
|
|||
The result of resolving _option_ values is a mapping of string identifiers to values. | |||
The result of resolving _option_ values is an unordered mapping of string identifiers to values. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This might be too strong. An implementation would not be incorrect to order the options internally--that would be an implementation detail. What's important is that functions cannot count on the ordering or make the ordering significant.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This has that effect. It's still possible for an implementation to use a container that retains order to represent the options, but with this qualifier functions can't rely on that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm trying to be parsimonious about what we change. The existing text doesn't say anything about order, thus you can't count on it (especially since we disallow ordering elsewhere). But I can live with this.
Closes #749.
See #716 for context.