Overloading of matcher method Was: Deconstruction patterns

[Brian Goetz]

Remi pointed out privately that I didn't answer this question directly 
enough for his satisfaction.

On 3/7/2023 9:20 AM, Brian Goetz wrote:
> class Foo {
>    public Foo(String s) { ... }
>    public Foo(CharSequence seq) { ... }
>
>    public matcher Foo(String s) { ... }
>    public matcher Foo(CharSequence seq) { ... }
> }
>
> If i want to call Foo(CharSequence) with a String, i can use a cast, 
> new Foo((CharSequence) "foo") and the compiler selects the right 
> overload.
>
> How i can do the same to select the right matcher method inside a 
> deconstructor pattern ? 

For the constructor, you can guide (but not force) overload selection to 
the answer you want by providing more type information, which in turn 
will steer the "most specific" selection:

     new Foo((String) s)
vs
     new Foo((CharSequence) s)

For the deconstructor, we can do something similar with type patterns.  
We can say:

     case Foo(String s):
vs
     case Foo(CharSequence s):

For both of these use sites, both matchers are applicable; we're left 
with a question of which is "more specific" to the types present at the 
use site.  As I have mentioned, the details are TBD, but we will draw 
inspiration from dualizing 15.12.2.5.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-spec-experts/attachments/20230307/f3ed20f2/attachment-0001.htm>