RE: A read on a WebGL overload

>> 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).



Ah, I realize now that I read the table incorrectly. I was looking at the column for numeric types and reading down to buffer source types, rather than finding the numeric types row and reading across the columns. Noob mistake. :-/



>> Yep.  This is true in the original overload case too.



Thanks for confirming!



From: Boris Zbarsky
Sent: Tuesday, September 29, 2015 2:48 PM
To: Travis Leithead;public-script-coord@w3.org;Justin Rogers
Subject: 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