Method dispatch ordering: should we traverse all multi values before checking the parent types?

[radeusgd]

Yet another issue encountered when working on #12165.

See this script:

from Standard.Base import all

type My_Atom
    Value a

    method_1 self = "My_Atom.method_1"

type My_Refinement
    Value x

    method_1 self = "My_Refinement.method_1"
    is_nothing self = "My_Refinement.is_nothing"

My_Refinement.from (that : My_Atom) -> My_Refinement =
    My_Refinement.Value that

prepare_atom =
    (My_Atom.Value 42) : My_Atom & My_Refinement

main =
    x = prepare_atom

    # This will call `method_1` on `My_Atom`, not on `My_Refinement`
    IO.println (x.method_1)

    # If I switch the order, then indeed `method_1` is called on `My_Refinement`
    IO.println ((x : My_Refinement & My_Atom).method_1)

    # This is currently calling `is_nothing` on `My_Refinement`, but shouldn't it call the base `is_nothing` coming from `Any`?
    IO.println (x.is_nothing)

    # What if I hide the refinement?
    IO.println ((x : My_Atom|Nothing).is_nothing)

Currently this yields:

My_Atom.method_1
My_Refinement.method_1
My_Refinement.is_nothing
False

As mentioned in the comments - currently if My_Atom does not define is_nothing, we first consider its intersection type and resolve to My_Refinement.is_nothing.

I suggest that this is wrong. My_Atom does have is_nothing defined. It is just not defined directly on it, but 'inherited' from Any. This 'inherited' definition is still directly available on My_Atom, so it should take precedence over the secondary refinement type.

[radeusgd]

The practical aspect of it is - I was trying to call is_nothing on a Table which is a safe operation.

But since #12165, a Table may also sometimes be a Column. When it is both, the is_nothing was now forwarded into Column.is_nothing and returning a new Column... I guess a side problem is that Column.is_nothing returning a Column is also not ideal...

But I think that does not make the dispatch problem smaller. If I have a method on the base type, it should be considered first before trying the 'secondary' values. Or are there any reasons why this shouldn't happen?

[JaroslavTulach]

• "what should EnsoMultiValue do with Any methods?" - Let EnsoMultiValue.to_text delegate to first type to_text #11827 asks
• Let EnsoMultiValue.to_text delegate to first type to_text #11827 - that's where @radeusgd wants to delegate the Any method to the first value
• multi_value.to doesn't work on second & further elements of intersection type #11935 - that's where we don't want to delegate the Any.to method to the first value