Skip to content

Name resolution for method calls is inconsistent #1397

@marzipankaiser

Description

@marzipankaiser

What should be the overloading/unboxing behavior, actually? Currently, it seems all over the place, to the best of my current understanding:
value.foo(...){...} (a) is different from block.foo(...){...} (b) is different from foo(...){...} (c).

  • (a) will be overloaded with just functions if there is a function foo  in scope, overloaded with just operations if there is an operation in scope, and only otherwise resolve to a block parameter of the innermost function that has any (the comment here is misleading); An unbox will be inserted if there is an operation in the CallTarget  afterwards. Implemented here:
    private[namer] def resolveOverloadedFunction(id: IdRef): Boolean = at(id) {
  • (b) will be overloaded with just operations if there is an operation in scope*, else overloaded with functions only, and never resolve to a block parameter. Implemented here:
    private[namer] def resolveOverloadedOperation(id: IdRef): Boolean = at(id) {
  • (c) will resolve to functions or block parameters, unless there is a value in a closer scope, in which case it will resolve to that. Implemented here:
    private[namer] def resolveFunctionCalltarget(id: IdRef): Unit = at(id) {

Examples where this acts weirdly:

Related issues

Possible directions for solutions

  • Move box-unbox-inference into typer and overload between all of them
  • Drop the distinction between blocks/values

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions