Fuzion Logo
flang.dev — The Fuzion Language Portal
JavaScript seems to be disabled. Functionality is limited.


Type Overloading

Overloading is convenient, it allows one method to be used for different types, as in Java's PrintStream.println():

void print​ln(boolean b)
void print​ln(char c)
void print​ln(char[] s)
void print​ln(double d)
void print​ln(float f)
void print​ln(int i)
void print​ln(long l)
void print​ln(Object obj)
void print​ln(String s)

Disadvantages of overloading include

An alternative to overloading that avoids these disadvantages might be choice types:

print​ln(x bool | char | Array<char> | f64 | f32 | i32 | i64 | String | Object)
  match x
    b bool        => printString(b ? "true" : "false"),
    c char        => printchar(c),
    a Array<char> => a | (c) -> printchar(c),
    f f64         => printF64(f),
    f f32         => printF32(f),
    i i64         => printF64(i),
    i i32         => printF32(i),
    s String      => printString(s),
    o Object      => printString("Some Object")

This avoids the duplication and ambiguity. It should also improve maintainability since the match statement should flag missing cases. Open questions

Argument Count Overloading

Overloading features with different argument counts is much easier than overloading with differnt types. Usually, the argument count is obvious.

Nervertheless, argument count overloading is complicated in Fuzion as follows.

Possible solutions:

Type declarations

A simple solution is just to forbid the use of features as type name in case there is overloading.

Alternatively, type syntax could be extended by an optional argument count parameters to resolve ambiguity: v t[3] to declare field v to be of the variant of type t with three arguments.

Open Generics

Again, overloading could be forbidden in cases where open generics would cause ambiguity.

Alternatively, the compiler front-end could be enhanced to handle it since eventually the actual number of arguments must be known after type inference.