Will fallback to a slow path disincentivize changing IDL constructs? about interface-types

[jgravelle-google]

It was considered, but IIRC the original proposal was to hard-error on mismatching signatures instead of falling back to a slower path. My guess is that that would cause much more hesitancy than a performance cliff.

Are there better solutions?

[annevk]

I'm not sure. It's probably worth pointing this out somewhere and perhaps in time also include a warning in the IDL specification itself to familiarize it among those writing specifications. With the goal that folks take even more care than usual to what gets written down.

[lukewagner]

Good point. I think there is a way to address this:

• There will be a spec predicate "does this imported function 'match' this Web IDL Binding?" that determines whether the fast or through-JS path is taken (it's subtly semantically visible, so testable).
• This predicate could accept bindings that pass a subset of the imports' parameters when the extra parameters are marked optional (the semantics being to pass the default value).
• The guidance is thus (if it isn't already, which I bet it is), if you extend a method, make sure the new parameters are marked "optional".

This does require specializing a binding's generated stub to the callee, but I've been assuming that that is generally necessary in my mental model of the implementation, for a variety of reasons.

[littledan]

This outline seems plausible, but this does not sound like a trivial relation to specify (and I imagine the implementation side would be even more complicated). About whether this is expressive enough: seems like this would catch cases like adding an entry to an enum in the browser but not the application code, but not rephrasing checks from spec prose to IDL (e.g., WebAssembly/spec#977). cc @Ms2ger.

[lukewagner]

I agree the relation will be complicated, but I think that is just inherent to the design, addressing not just this, but all the other bullets under Question #2 in the explainer that we discussed earlier.

Adding cases to enums or optional fields to dictionaries should independently fall out of the "structural subtyping" aspect of the design (mentioned in the Web IDL Types section of the explainer) of how value types are passed.

[pchickey]

Closing as out-of-date: the proposal no longer has the same sort of relationship to WebIDL as it did during this discussion. I don't think most of these concerns apply anymore. If I am incorrect, please re-open :)