Skip to content
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

Tweak a few fields docs #99

Merged
merged 2 commits into from
Feb 20, 2024
Merged

Conversation

acfoltzer
Copy link
Contributor

  • This patch clarifies the behavior of the various fields methods when syntactically invalid inputs are given. Some methods already noted this, but get in particular was missing a clarification that an invalid key would result in an empty list result

  • Removed some text in the doc for from-list. While non-UTF-8 values are not preferred for new applications, they are syntactically valid due to the obs-text production in the RFC grammar.

- This patch clarifies the behavior of the various `fields` methods when syntactically invalid
  inputs are given. Some methods already noted this, but `get` in particular was missing a
  clarification that an invalid key would result in an empty list result

- Removed some text in the doc for `from-list`. While non-UTF-8 values are not preferred for new
  applications, they are syntactically valid due to the [`obs-text`
  production](https://www.rfc-editor.org/rfc/rfc9110#section-5.5-2) in the RFC grammar.
Copy link
Member

@lukewagner lukewagner left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks right to me, nice spots!

Separately, and of interest to the WASI Subgroup process for post-0.2.0 evolution, we should discuss how these changes get published. My inclination is that, since the changes are essentially editorial, this is still part of 0.2.0 so maybe we just update the WASI Preview 2 snapshot in-place? (cc @pchickey @sunfishcode @ricochet )

/// empty field-values present.
/// in this `fields` or is syntactically invalid, an empty list is returned.
/// However, if the key is present but empty, this is represented by a list
/// with one or more empty field-values present.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems like the right choice given that 0.2.0 is frozen and we can't change the types. But the next time we can make a breaking change (e.g., 0.3.0), I wonder if a syntactically-invalid key parameter should produce an error and thus the return value should be wrapped in a result? The answer doesn't affect this PR, but separately we could start a list of "pending tweaks for 0.3.0" if we agree.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that would be more consistent with the other methods, and would support carrying it forward as a proposed change for 0.3.0.

@pchickey
Copy link
Contributor

pchickey commented Feb 5, 2024

With regard to pushing docs improvements up to the snapshot in the root WebAssembly/WASI repo - lets make sure that whatever editorial changes are discussed in the proposals themselves, and then I can mechanically update the version we "publish" there as needed.

@elliottt elliottt merged commit 32da63e into WebAssembly:main Feb 20, 2024
1 check passed
@acfoltzer acfoltzer deleted the acf/fields-docs branch February 21, 2024 19:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants