21295 2013-03-14 23:53:25 +0000 overload resolution: are DOMString and sequence<T> distinguishable now? 2013-08-04 09:10:30 +0000 1 1 1 Unclassified WebAppsWG WebIDL unspecified PC Windows NT RESOLVED INVALID [v1] P2 normal --- 1 travil cam annevk bzbarsky jsbell mike public-script-coord public-webapps-bugzilla oldest_to_newest 84453 0 travil 2013-03-14 23:53:25 +0000 In the Screen Orientation spec: http://www.w3.org/TR/screen-orientation/#extensions-to-the-screen-interface the interface specifies an overload between a sequence<DOMString> and a DOMString: boolean lockOrientation (DOMString orientation); boolean lockOrientation (sequence<DOMString> orientations); So, when an implementation gets a DOMString as a parameter, I wondered how I could tell whether I should apply the sequence<> conversion logic, or take the DOMString as-is? The sequence<T> conversion logic would seem to take a DOMString "Hi", and per section 4.2.24: http://dev.w3.org/2006/webapi/WebIDL/#es-sequence I'd fall through to the "Any kind of object except for a native Date object or a native RegExp object" rule. DOMString's have a length (2 in this case), so I'd end up either taking the DOMString as is (one viable outcome) or converting the DOMString into ["H", "i"] per 4.2.24 (equally valid outcome). I think that means that these two types are not distinguishable anymore? Somehow I don't think that's the intent... 84455 1 bzbarsky 2013-03-15 01:13:40 +0000 DOMString and sequence are distinguishable, yes. As for how you decide which overload is being called, that's described at http://dev.w3.org/2006/webapi/WebIDL/#dfn-overload-resolution-algorithm In this case, step 13 is reached with i == 0. The substeps of step 13 are followed, you skip step 7 because V is not an object, and then step 8 treats it as a DOMString. That's assuming what's passed in is a primitive string. If a JS String object is passed in, it will in fact be treated as a sequence the way the spec is currently written, as far as I can tell. That might be worth fixing.... 90585 2 annevk 2013-07-10 13:53:45 +0000 Note that "DOMString, DOMString..." or maybe just "DOMString..." would be preferable signature. 91614 3 cam 2013-08-04 09:10:30 +0000 As Boris says, these are distinguishable now, and the rules in #dfn-overload-resolution-algorithm should work.