On Oct 11, 2012 5:51 PM, "Boris Zbarsky" <bzbarsky@mit.edu> wrote: > > On 10/11/12 8:43 PM, Jonas Sicking wrote: >> >> Even for an API like: >> >> void bar(optional int x); >> void bar(MyInterface? x); >> >> with or without the "treat undefined as not-passed" rule, it's >> definitely not obvious which one >> >> bar(undefined); >> >> would call. I think the WebIDL spec unambiguously makes it match the >> second one, but I wouldn't call that obvious to authors. > > > It's the second one as written. If the int arg there were [TreatUndefinedAs=Missing], then the first overload would be chosen, as WebIDL is written today. And if we made undefined default to missing, it would presumably be the first one in this example. I think that whatever we choose to do here, patterns like the ones in your or my example aren't going to be obvious to web authors. Which is why I think we should discourage them in prose or in rules in WebIDL. >> In general, WebIDL is ultimately a spec aimed at spec authors, not at >> developers. We have to make spec authors assume some level of >> responsibility for the APIs that they create. > > > I'm not that sanguine about it so far, but maybe that's because most spec authors so far don't really understand WebIDL very well... I somewhat agree, but I don't think that anything we do here is going to have a big effect on what spec authors do. >>> If so, all we're really saying is that overload resolution will drop >>> _trailing_ undefined from the argc before determining the overload to use, >>> right? >> >> >> If we go with option B above, then doing that sounds good yes. > > > I can live with that. For what it's worth, I'm fine with either function getting selected from your original example. / Jonas
Received on Friday, 12 October 2012 07:30:06 UTC