W3C home > Mailing lists > Public > public-script-coord@w3.org > July to September 2015

Re: A read on a WebGL overload

From: Boris Zbarsky <bzbarsky@mit.edu>
Date: Tue, 29 Sep 2015 17:47:54 -0400
To: Travis Leithead <travis.leithead@microsoft.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>, Justin Rogers <justrog@microsoft.com>
Message-ID: <560B070A.9000600@mit.edu>
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 

   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.

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:24 UTC