[Webkit-unassigned] [Bug 176333] New: WSL overload resolution should not be cascading

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=176333

            Bug ID: 176333
           Summary: WSL overload resolution should not be cascading
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: All
                OS: All
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: WebGPU
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: fpizlo at apple.com

Currently WSL resolves overloads by just proceeding through signatures in order, and returning the first one that matches.  That's pretty weird.  For example, it means that if someone uses #include as a mechanism of modularity, then the order in which things are included will determine what gets called.  This is in contrast to C++, which has fairly deterministic overload resolution rules that will often report overload ambiguity errors in cases where things would have gotten weird.  Also, regardless of what you think of cascading overload resolution versus C++ overload resolution, it is a goal of WSL to be similar to C++.  So, this implies having some deterministic rules like C++ does.

I propose the following.  When there are N matches where N is greater than 1, they are ranked according to how they used inferred type variables.  Those are type variables that were not defined by type arguments to the call.  The math for this will be done using rational numbers with bignum numerators and denominators for maximum determinism.  The ranking formula gives each parameter a point.  If the parameter does not mention any inferred type variables, it gets one point.  If it is nothing more than just a reference to a type variable and the type variable has no protocol, then it gets zero points.  In general, we give it points recursively, so that you get more than zero points if the type variable is mentioned in some context like T^ or Foo<T>.  For example:

    points(ptrType) = points(ptrType.elementType) * 3/4 + 1/4;

For type variables, we give 1/3 point if it mentions a protocol, and zero points otherwise.

This enables us to do overload resolution in obvious cases:

void foo(int); // Obviously more specific!
void foo<T>(T);

And give errors in cases that feel like they should get errors:

void foo<T>(int, T);
void foo<T>(T, int);

Cases that are more specific by having a more specific protocol will be resolved unambiguously:

void foo<T:numeric>(T); // More specific!
void foo<T>(T);

But we will give errors if things get any weirder:

void foo<T:numeric>(T);
void foo<T:primitive>(T);

This will be an error even though numeric is a more specific protocol than primitive. I think that's the right call just because if we make it any more complicated, then we make our lives a lot harder with probably not a whole lot of benefit for anybody.  I think that a lot of users would expect an error here.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20170904/3deaff1b/attachment.html>