Re: [heycam/webidl] Does the "required" dictionary member keyword affect output? (#382)

Here's the way I think of it.  `required` is a restriction on the data model of the dictionary.  A dictionary with a `required` member cannot be instantiated, conceptually, without that member being present.

This has implications for the ES-to-dictionary conversion, of course.  But it also has implications for the dictionary-to-ES conversion, in that you know that property will exist on the resulting object.

I don't know whether we need to explicitly describe "valid" vs "invalid" dictionaries or something...  The only "invalid" ones would be dictionaries with `required` members that are in the middle of being created via <https://heycam.github.io/webidl/#es-to-dictionary> or dictionaries with `required` members that spec prose creates without defining values for those members.  Converting an "invalid" dictionary to ES would not be possible.

Similarly, a dictionary that has a member with a default value will always have that member present, conceptually. 

> Both hinge on the definition of "present".

I think the right thing here is to have the "present" in the spec bits you quoted mean "internal invariant".

How this internal invariant is maintained is a bit less clear.  Nothing at the moment really prevents a specification from creating an "invalid" dictionary in the sense described above.  In terms of implementation, at least Gecko handles it as follows: the internal representation assumes there is a value for every required or defaulted property, on from-ES conversion the bindings enforce the existence of a value, on to-ES conversion the bindings assume the relevant member of the C++ struct has been properly initialized.  It's possible for this last to fail if the C++ programmer messes up...

> AFAICT our WebIDL compiler does not do anything to enforce presence of "required" internal values when output

Right, this is the "C++ programmer messes up" case.  What it will do is try to convert uninitialized memory to an ES value and chances are hilarity of the "random output, crashes, etc" sort will ensue.  But that's an implementation detail.  We could just as easily have made the concept of "valid" vs "invalid" explicit in Gecko's C++ dictionary implementation and made to-ES conversion fail for dictionaries with uninitialized required members....  This isn't really an IDL spec issue.

> where people are considering using required on output-only dictionaries as a form of normative implementation implication.

This seems pretty reasonable to me, fwiw.

> and what we might expect WebIDL compilers to enforce in the future.

That's an implementation detail that shouldn't be relevant here, imo.

> Ultimately the requirement for what to return comes from the prose

Well, a combination of the dictionary definition and the prose, right?  The prose says what things are present in the map; the dictionary definition defines how to convert that map to ES.

> required and default values only apply to the input side of dictionaries. 

In terms of normative steps in IDL, yes, but in terms of conceptual model I believe they apply to the dictionary type itself, per above.



-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/heycam/webidl/issues/382#issuecomment-315553336