Re: A read on a WebGL overload

On 9/29/15 5:17 PM, Travis Leithead wrote:
> Some folks on the Edge team are debating how to handle this case from
> WebGL when passed the literal *undefined* as param 2:
>
>      void bufferData(GLenum target, GLsizeiptr size, GLenum usage);
>
>      void bufferData(GLenum target, BufferDataSource? data, GLenum usage);
>
> typedef (ArrayBuffer or ArrayBufferView) BufferDataSource;
>
> typedef long long GLsizeiptr
>
>  From my read on WebIDL, the second params in each of these overloads
> does not pass the distinguishability test:
>
> 1.Numeric type + buffer source types are not distinguishable

Er... why not?  The table at 
http://heycam.github.io/webidl/#dfn-distinguishable lists them as 
distinguishable from everything else (but not from each other, as you note).

> 2.Each member of the BufferDataSource union type is not distinguishable

Yes, this is a bug in the spec as currently written.  This used to be 
right back when these were interface types defined in IDL, and the 
change to use the ES types here wasn't done quite right.  This is what 
<https://github.com/heycam/webidl/issues/50> is about.

> 3.Req. 3 is not applicable.

Right, because these are not both unions.

> Does this constitute a violation of WebIDL? Or did I read this wrong?

The only issue here is <https://github.com/heycam/webidl/issues/50> as 
far as I can tell.

> then I think it becomes clear according to the conversion rules for
> union types, to pass *null* to the implementation.

Yep.  This is true in the original overload case too.  Walking through 
http://heycam.github.io/webidl/#dfn-overload-resolution-algorithm the 
distinguishing argument index is 1, and we end up in step 11 substep 3, 
which says (at this point we have i == 1, so looking at the second 
argument):

   Otherwise: if V is null or undefined, and there is an entry in S that
   has one of the following types at position i of its type list,

   * a nullable type
   * a dictionary type
   * a union type that includes a nullable type or that has a dictionary
     type in its flattened members

   then remove from S all other entries.

In this case, there is exactly one nullable type at position 1, which is 
the "BufferDataSource?" and there are no dictionary types in sight, so 
the overload taking "BufferDataSource?" is selected and then undefined 
becomes null in the usual way when passed for a nullable type.

-Boris

Received on Tuesday, 29 September 2015 21:48:24 UTC