Re: [whatwg/encoding] Editorial: require returned dictionary members (#185)

Sure.

I don't think we should be changing standard text to help code generators, unless the benefit is overwhelming for the additional cost and complexity. Here we are told that this helps Gecko in some way, but this doesn't meet the bar, in my opinion.

More troubling is the overloading of the "required" keyword. It has a normative, useful impact on input dictionaries. We encourage specification authors to use it in specific ways because of that impact. Saying that it should also be used for output dictionaries, for a completely different purpose---something which has no processing model impact, but instead is documentation/helpful for Gecko's code-gen---muddles the definition and usage of required dictionary members.

If we're looking for documentation that a dictionary is always used for output, we should document *that fact*, e.g. via a `// always output` or `// all members used when this is returned by encodeInto` comment. You know, documentation. We shouldn't have people indirectly infer that fact from noting that all members are required, and then having to check all the algorithms to find out oh, this isn't the usual "required as input" required, this is the "is always set by the spec" required.

If we're looking to improve Gecko's codegen, then Gecko should use Gecko-specific extended attributes.

Even if we had a lot of engines and parts of the ecosystem excited about codegen benefits, so as to meet the bar I mentioned earlier about putting the codegen hint in the spec, I again think overloading required is not the right way to introduce such hints; a [AlwaysSet] extended attribute would be better for that purpose.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/encoding/pull/185#issuecomment-540466320