Omit type-notations on a definite method bind

I made a function relying heavily on callbacks:

def broadth_first_search(
  spread : State->Array(State),
  finish : State->Bool,
  start_state : State
) : Array(State)? forall State
  # calculate ad return a path from start_state to a state that satisfy `finish`

and I wrote two sub-methods to call it

# `MyState` is an existing class
def spread_state(current : MyState) : Array(MyState)
def can_finish(current : MyState) : Bool

and on calling this bfs method, I have to add type annotation again on each proc literal:

if path = broadth_first_search(

here since all needed methods have been typed and there are no conflicting overloads, can a proc literal refer to the just method, thus binding to this method needs no extra type annotations?

def plus_one(x)
add1 = ->plus_one(Int32) # ok
def typed_plus_one(x : Int32) 
error_add1 = ->typed_plus_one # error, but can be deduced
typed_add1 = ->typed_plus_one(Int32) # ok

In the document, zero-argument method can be definitely referred because they only differ by name, so notating its name can identify its body.

def one
proc_one = ->one # ok

If other method are Identical enough, can they be similarly identified?

Is the feature forbidden by design, or abandoned due to implementation complexity?

error_add1 = ->typed_plus_one # error, but can be deduced

What happens if someone adds an overload to typed_plus_one? That code will stop to compile. That means that if we introduce this feature and a proc is taken like that, it prohibits defining overloads for that method.

Plain variable assignments cannot be deduced that way, but it should work if the -> appears in the argument to broadth_first_search directly. It would then break only if a different overload takes a different Proc type in that position. We do this for lib funs already.

Also there was a request somewhere to allow ->one() to refer to an explicitly parameter-less Proc.

Is it because argument of bfs has a clearer type restriction? As you say, lib functions can deduce proc parameter types. Comparing to user functions, lib functions don’t change frequently.

I noticed that C lib funcs don’t have generic arguments.If I write


should the compiler:

  • figure out “type argument State is MyState”,and then identify ->spread_state to ->spread_state(MyState) (after all,this is its only overload), and other proc arguments

or should it:

  • cancel guessing this type arguments, and directly refuse to compile