Closed annevk closed 5 years ago
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?
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.
Good point. I think there is a way to address this:
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.
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., https://github.com/WebAssembly/spec/pull/977). cc @Ms2ger.
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.
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 :)
A potential issue that occurred to me is that if a specification decides to change the signature of a method to enable new functionality or clean up some prose by making use of new IDL functionality implementations might not be eager to make these changes anymore as they could result in significant performance regressions on important sites.
It wasn't entirely clear to me whether this was considered.