- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Thu, 06 Jun 2013 13:18:13 -0400
- To: Jonas Sicking <jonas@sicking.cc>
- CC: DOM public list <www-dom@w3.org>, Anne van Kesteren <annevk@annevk.nl>, Cameron McCormack <cam@mcc.id.au>, "public-script-coord@w3.org" <public-script-coord@w3.org>
On 6/6/13 1:01 PM, Jonas Sicking wrote: > It also has the advantage > that the Future implementation doesn't need to spend time looking for > 'undefined' and treating it differently. If you mean the C++ implementation, that's ... unclear. There is no way to write "optional any foo = undefined" in WebIDL, and furthermore no such concept in ES in general. Which brings us to an interesting difference in default arguments between current WebIDL and ES, by the way. In WebIDL, an optional argument is either "not passed" or has a value. Arguments with a default value are never "not passed". For an optional argument of type "any", you can tell apart "not passed" and "undefined was passed explicitly", unless it's marked as [TreatUndefinedAs=Missing]. In ES, an argument is either "not passed" (as determined by arguments.length) or has a value. Arguments with a default value can in fact be "not passed" in that default values do not affect the arguments object at all. For example: function f(arg = 5) { alert(arg + " " + arguments[0]); } f(); alerts "5 undefined". Furthermore, even when an argument was passed its default value will still kick in if undefined is passed. I'd like to claim that the ES semantics here where default values don't affect the arguments object are pretty weird and seem like a footgun when combined with call/apply on the arguments object, but I assume there's a reason for them... In any case, the question is how to reconcile the two sanely. Once that's done, I fully expect the simplicity of the C++ implementation here to be nonexistent. -Boris
Received on Thursday, 6 June 2013 17:18:49 UTC