<p>By <em>overloading</em>, I mean allowing multiple type members that seem to conceptually do the same thing to use the same name, but possibly with different representations of the inputs.</p>
<pre><code>class Double {
  // Parses a number or fails
  static from(s: String): Optional&lt;Double&gt; { ... }
  // The numerically closest Double to i
  static from(i: Int): Double { ... }
}
</code></pre>
<p>so that <code>Double.from(text)</code> and <code>Double.from(123)</code> both work.</p>
<p>Another use case is spot optimizations.</p>
<pre><code>class ImmutableList&lt;T&gt; {
  // An empty list
  static &lt;T&gt; of(): ImmutableList&lt;T&gt; { ... }
  // A with a single element, a
  static &lt;T&gt; of(a: T): ImmutableList&lt;T&gt; { ... }
  // A with two element, a and b, in that order
  static &lt;T&gt; of(a: T, b: T): ImmutableList&lt;T&gt; { ... }
  // A list with the given elements in order
  static &lt;T&gt; of(varargs elements: T): ImmutableList&lt;T&gt; { ... }
}
</code></pre>
<p>Overloading here allow common uses to avoid allocating storage for a variable number of arguments under the hood.</p>
<p>There, overloading is <em>declaration-site</em>.  The same name is used where the members are declared.</p>
<p>This works when:</p>
<ul>
<li>a typed language compares arguments and required return type context to the signatures to eliminate most overloads from consideration</li>
<li>and/or the language combines multiple definitions with implied instructions that compare arguments to expectations and pick one definition to apply at runtime</li>
</ul>
<hr />
<p>It seems like a language definition could do away with declaration-site overloading and allow function dispatch rules to enable the same use cases.</p>
<pre><code>class Double {
  // The first code sample but with distinct names
  static fromString(s: String): Optional&lt;Double&gt; { ... }
  static fromInt(i: Int): Double { ... }
}
</code></pre>
<p>Perhaps we might <a href="https://en.wikipedia.org/wiki/Text_segmentation" rel="nofollow noreferrer">segment</a> identifiers based on camel-case transitions and/or underscores.</p>
<ul>
<li><code>fromString</code> -&gt; [<code>from</code>, <code>String</code>]</li>
<li><code>fromInt</code> -&gt; [<code>from</code>, <code>Int</code>]</li>
</ul>
<p>And a call like <code>.from_</code> (where the trailing <code>_</code> means etcetera) might potentially dispatch to any available member that starts with segments [<code>from</code>].</p>
<hr />
<p>What are the benefits and drawbacks to either approach?  In a typed or untyped language?</p>
<p>Backwards compatibility concerns?</p>

<dynamic-dispatch><overloading><static-dispatch>
Declaration-site vs use-site overloading
CC BY-SA 4.0
2023-07-18T18:06:35.523Z
It's a bit unclear what you mean. You gave an example of overloading, one of not-overloading, and then there is this segment identifier thing for which you give neither an example of how you would declare a class nor how you would use those. And isn't it just the same as template notation, like `from<String>()` and `from<Int>()`?
G. Sliepen
CC BY-SA 4.0
2023-07-18T22:40:27.710Z
@G.Sliepen, above the hrule are examples of declaration-site overloading and below the rule, examples of getting the ergonomics of overloading at the use site.

Yes, a Rust-like trait system allows a different way of handling specifically the from example, and more generally, differently typed expressions of the same notional category.  So maybe these different affordances would be necessary in fewer cases there.
iiuc, non-monomorphizing languages tend not to do that.
Mike Samuel
CC BY-SA 4.0
2023-07-19T11:25:00.687Z
So you mean that if you call `Double.from(123)`, the compiler takes the name of the type of the first argument, appends that to the function name, and then calls `Double.fromInt(123)`? If so, that's a bit unsafe, but actually not much different from what happens under the hood with the declaration-site overloading. C++ makes that more clear; it uses [name mangling](https://en.wikipedia.org/wiki/Name_mangling) to implement overloading.
G. Sliepen
CC BY-SA 4.0
2023-07-20T16:26:34.000Z
@G.Sliepen I was thinking that the use site would opt into name expansion.  `Double.from_(123)` would do as you describe.  Without the opt-in, I worry that type authors would have a hard time adding methods in a backwards compatible way unless there's a guaranteed stable way to refer to a particular method.  With the opt in, type authors can group related methods together with a common prefix and allow succinct type-aware dispatch.
Mike Samuel
CC BY-SA 4.0
2023-07-24T17:53:26.077Z
Does this answer your question? [What are the alternatives to classic ad hoc function overloading?](https://langdev.stackexchange.com/questions/1603/what-are-the-alternatives-to-classic-ad-hoc-function-overloading)
ratchet freak
CC BY-SA 4.0
2023-07-25T16:59:50.687Z
@ratchetfreak.  Thanks, but no.  I'm not interested in alternate dispatch models like traits and multimethods.  That seems orthogonal to how members are named.  My interests are mostly in how things like having a distinct canonical name for a method (distinct barring overriding) simplifies other aspects of the language, IDE refactorings and typeahead, and user ergonomics.
Mike Samuel
<p>A major disadvantage is that it relies on naming to implement a feature that can be implemented only using type information. This looks more like something that would exist in a macro language like \TeX where you don't really have types.</p>
<p>Here you mix namespace concerns with typing concerns, for no particular benefit as far as I know. For example if you wan to implement <code>from</code> for both <code>a::b::Date</code> and <code>x::y::z::Date</code>, then your names need to be qualified (assuming you have packages/namespaces). This means supporting that syntax in function identifiers. Likewise for arrays, or pointers, I don't know.</p>
<p>I am not sure how you declare that <code>from</code> is a prefix for dispatching, is this built-in? Or are the segments tried for different types? Does this limit the kind of names I can use, because that's annoying.</p>
<p>For example, if I want to name my method <code>toString</code>, is the <code>String</code> part of a type dispatch mechanism or part of the name? Moreover, some types could be unnamed (function application) or cumbersome to write.</p>

CC BY-SA 4.0
2023-07-19T16:08:31.140Z
2023-07-19T16:08:31.140Z
coredump
CC BY-SA 4.0
2023-07-19T17:16:24.597Z
In use-site overloading, one does not have to declare prefixes for dispatching.

There would be no need to try the segments for types that are not super-types of the receiver type, or for namespaces other than the receiver namespace.

`toString` segments to [*to*, *String*], so code in a typed language like `let s: String = x.to_()` might statically rewrite to `let s: String = x.toString()` by filtering for compatibility with an empty argument list and an output type that's a subtype of `s`'s declared type.
Mike Samuel
CC BY-SA 4.0
2023-07-19T17:31:35.320Z
I don't understand why the input code would be `x.to_()`, I would write `x.toString()`, maybe it's a bad example but I was thinking about a case where segments could clash with type names. Thanks for your comment I see a bit better what you are thinking about.
coredump
CC BY-SA 4.0
2023-07-19T17:35:36.870Z
Sorry, I think we're talking at cross purposes.  The input code is `x.to_()` because the programmer wants to use shorthand.
Mike Samuel
CC BY-SA 4.0
2023-07-19T19:05:57.443Z
Yes but my point is I would like to have names that makes sense at a business level. Another method name could be "getCharClass" where char is a character in a DnD campaign and class is their DnD class. The name would match existing type names (char and class)
coredump
CC BY-SA 4.0
2023-07-20T16:21:59.070Z
What is the significance of *getCharClass* matching those type names?  I suspect that I've not explained the use-site semantics because I don't see anything in either the declaration-site scheme or the use-site scheme that would complicate that.
Mike Samuel
# Declaration-site vs use-site overloading
Posted by: username_0 on 2023-07-18
By overloading, I mean allowing multiple type members that seem to conceptually do the same thing to use the same name, but possibly with different representations of the inputs.
class Double {
  // Parses a number or fails
  static from(s: String): Optional { ... }
  // The numerically closest Double to i
  static from(i: Int): Double { ... }
}

so that Double.from(text) and Double.from(123) both work.
Another use case is spot optimizations.
class ImmutableList {
  // An empty list
  static  of(): ImmutableList { ... }
  // A with a single element, a
  static  of(a: T): ImmutableList { ... }
  // A with two element, a and b, in that order
  static  of(a: T, b: T): ImmutableList { ... }
  // A list with the given elements in order
  static  of(varargs elements: T): ImmutableList { ... }
}

Overloading here allow common uses to avoid allocating storage for a variable number of arguments under the hood.
There, overloading is declaration-site.  The same name is used where the members are declared.
This works when:

a typed language compares arguments and required return type context to the signatures to eliminate most overloads from consideration
and/or the language combines multiple definitions with implied instructions that compare arguments to expectations and pick one definition to apply at runtime


It seems like a language definition could do away with declaration-site overloading and allow function dispatch rules to enable the same use cases.
class Double {
  // The first code sample but with distinct names
  static fromString(s: String): Optional { ... }
  static fromInt(i: Int): Double { ... }
}

Perhaps we might segment identifiers based on camel-case transitions and/or underscores.

fromString -> [from, String]
fromInt -> [from, Int]

And a call like .from_ (where the trailing _ means etcetera) might potentially dispatch to any available member that starts with segments [from].

What are the benefits and drawbacks to either approach?  In a typed or untyped language?
Backwards compatibility concerns?
**Tags:** dynamic-dispatch overloading static-dispatch
> **Comments:**
> **username_1**: It's a bit unclear what you mean. You gave an example of overloading, one of not-overloading, and then there is this segment identifier thing for which you give neither an example of how you would declare a class nor how you would use those. And isn't it just the same as template notation, like `from<String>()` and `from<Int>()`?  
> **username_0**: @G.Sliepen, above the hrule are examples of declaration-site overloading and below the rule, examples of getting the ergonomics of overloading at the use site.

Yes, a Rust-like trait system allows a different way of handling specifically the from example, and more generally, differently typed expressions of the same notional category.  So maybe these different affordances would be necessary in fewer cases there.
iiuc, non-monomorphizing languages tend not to do that.  
> **username_1**: So you mean that if you call `Double.from(123)`, the compiler takes the name of the type of the first argument, appends that to the function name, and then calls `Double.fromInt(123)`? If so, that's a bit unsafe, but actually not much different from what happens under the hood with the declaration-site overloading. C++ makes that more clear; it uses [name mangling](https://en.wikipedia.org/wiki/Name_mangling) to implement overloading.  
> **username_0**: @G.Sliepen I was thinking that the use site would opt into name expansion.  `Double.from_(123)` would do as you describe.  Without the opt-in, I worry that type authors would have a hard time adding methods in a backwards compatible way unless there's a guaranteed stable way to refer to a particular method.  With the opt in, type authors can group related methods together with a common prefix and allow succinct type-aware dispatch.  
> **username_2**: Does this answer your question? [What are the alternatives to classic ad hoc function overloading?](https://langdev.stackexchange.com/questions/1603/what-are-the-alternatives-to-classic-ad-hoc-function-overloading)  
> **username_0**: @ratchetfreak.  Thanks, but no.  I'm not interested in alternate dispatch models like traits and multimethods.  That seems orthogonal to how members are named.  My interests are mostly in how things like having a distinct canonical name for a method (distinct barring overriding) simplifies other aspects of the language, IDE refactorings and typeahead, and user ergonomics.  
---
## 1 answers
### Answer by username_3 on 2023-07-19. Score: 5
A major disadvantage is that it relies on naming to implement a feature that can be implemented only using type information. This looks more like something that would exist in a macro language like \TeX where you don't really have types.

Here you mix namespace concerns with typing concerns, for no particular benefit as far as I know. For example if you wan to implement `from` for both `a::b::Date` and `x::y::z::Date`, then your names need to be qualified (assuming you have packages/namespaces). This means supporting that syntax in function identifiers. Likewise for arrays, or pointers, I don't know.

I am not sure how you declare that `from` is a prefix for dispatching, is this built-in? Or are the segments tried for different types? Does this limit the kind of names I can use, because that's annoying.

For example, if I want to name my method `toString`, is the `String` part of a type dispatch mechanism or part of the name? Moreover, some types could be unnamed (function application) or cumbersome to write.
> **Comments:**
> **username_0** (2023-07-19): In use-site overloading, one does not have to declare prefixes for dispatching.

There would be no need to try the segments for types that are not super-types of the receiver type, or for namespaces other than the receiver namespace.

`toString` segments to [*to*, *String*], so code in a typed language like `let s: String = x.to_()` might statically rewrite to `let s: String = x.toString()` by filtering for compatibility with an empty argument list and an output type that's a subtype of `s`'s declared type.  
> **username_3** (2023-07-19): I don't understand why the input code would be `x.to_()`, I would write `x.toString()`, maybe it's a bad example but I was thinking about a case where segments could clash with type names. Thanks for your comment I see a bit better what you are thinking about.  
> **username_0** (2023-07-19): Sorry, I think we're talking at cross purposes.  The input code is `x.to_()` because the programmer wants to use shorthand.  
> **username_3** (2023-07-19): Yes but my point is I would like to have names that makes sense at a business level. Another method name could be "getCharClass" where char is a character in a DnD campaign and class is their DnD class. The name would match existing type names (char and class)  
> **username_0** (2023-07-20): What is the significance of *getCharClass* matching those type names?  I suspect that I've not explained the use-site semantics because I don't see anything in either the declaration-site scheme or the use-site scheme that would complicate that.  
---
