Re: Removing the concept of "optional any"

On 2/19/14 11:28 AM, Mark S. Miller wrote:
> Everything here seems good and compat except the .length issue. Wouldn't
> this change cause existing .length values to change, without any other
> observable effect on semantics?

There is an observable effect, in the cases when .length changes.

Right now per WebIDL, if you have this IDL:

   void f(any arg);

then that function has length 1 and you call f() with no arguments you 
get an exception.  After the proposed change it will have length 0 and 
calling f() with no arguments will just behave as if you had explicitly 
passed undefined.

I agree that this is a possible compat issue in that calls that used to 
throw will now no longer throw.   For the record, the full set of 
standards-track things (so excluding gecko-specific stuff) affected by 
that change in Gecko is:

1)  DedicatedWorkerGlobalScope.postMessage.  Right now it requires 
explicitly passing a message, but with the change you could pass 
undefined by passing no arguments.
2)  IDBCursor.update.
3)  IDBFactory.cmp.  Throws no matter what if undefined or null are 
passed; maybe this should not be using "any" to start with.
4)  IDBIndex.get and IDBIndex.getKey.  Both seem to throw if null or 
undefined are passed, since those are not valid keys.
5)  IDBKeyRange.only.  This throws on undefined anyway, since that's not 
a valid key.
6)  IDBKeyRange.lowerBound.  Same thing.
7)  IDBKeyRange.upperBound.  Same thing.
8)  IDBKeyRange.bound.  Same thing.
9)  IDBObjectStore.add
10) IDBObjectStore.put
11) IDBObjectStore.delete.  Throws on undefined: invalid key.
12) IDBObjectStore.get.  Throws on undefined: invalid key.
13) MessagePort.postMessage
14) Worker.postMessage

That's it.  So broadly speaking, the postMessage implementations, the 
IDB abuse of "any" when they really mean "(object or DOMString or 
unconstrained double)" or some such, and the update/add/put IDB bits.  I 
somewhat doubt anyone is relying on those throwing when called with no 
arguments.

-Boris

Received on Wednesday, 19 February 2014 17:02:15 UTC