<p>What are the pros and cons of allowing users to define functions with the same name as built-in functions?</p>
<p>For example, defining:</p>
<pre><code>max(a, b) {
    if a &gt; b return a;
    else return b;
}
</code></pre>
<p>as a repeat of the already existing <code>max()</code> function in some languages.</p>
<p>Or defining:</p>
<pre><code>min(a, b) {
    if a &gt; b return b;
    else return a;
}
</code></pre>
<p>as a repeat of <code>min()</code>.</p>
<p>What are the pros and cons of letting users define functions like the ones listed above?</p>

<functions><built-ins>
What are the pros and cons of letting users define functions with the same name as builtin functions?
CC BY-SA 4.0
2023-06-20T04:22:02.473Z
Relevant Meta discussion: https://languagedesign.meta.stackexchange.com/questions/370/can-i-ask-this-question
FireTheLost
CC BY-SA 4.0
2023-06-20T04:22:32.160Z
Why has the question been downvoted? It seems to be reasonable.
FireTheLost
CC BY-SA 4.0
2023-07-16T01:59:14.350Z
To be pedantic, I'd define `min` using the `<` test. E.g I can think of objects where `a>b` and `a<b` can both be true.
Ray Butterworth
CC BY-SA 4.0
2023-07-17T17:01:30.217Z
Is this question only for languages without namespaces/packages (for standard library functions, at least)?
gidds
<p>The programmer may not be aware that some system function has been called and not a user-defined one. Even if the user-define function has a priority, this may depend on some import or header statement missing.</p>
<p>This is usually addressed by marking the built-in functions the way user defined functions should never be marked (<code>__function</code>, <code>JFunction</code>, <code>std::function</code> and the like), even when it makes the code more cluttered. For instance, C++ has many functions with quite common names (<code>tie</code>, <code>pair</code>, <code>map</code>) that can be easily re-invented. In some cases the code may actually compile by some chance, creating bugs that take time to find. While in old Java AWT there was a Button, in the later Swing this has been changed to JButton.</p>

CC BY-SA 4.0
2023-06-30T08:21:52.783Z
2023-06-30T08:21:52.783Z
Audrius Meškauskas
<h3>Pro: New builtins won't break old programs.</h3>
<p>Perhaps the programmer wrote that <code>max()</code> function because the builtin was not available in a previous version of the programming language. If the language does not allow user functions to shadow builtins, then if the language introduces a new builtin it may break old programs that were already using that name.</p>

CC BY-SA 4.0
2023-06-20T06:04:46.913Z
2023-06-23T19:58:55.653Z
2023-06-23T19:58:55.653Z
hugomg
CC BY-SA 4.0
2023-07-17T17:06:52.210Z
If a language has a means of indicating "the programmer is aware that a built-in with the same name as this function may exist, and if it does it would be equally acceptable to call the built-in or this function", such a feature may allow programs to be written in ways that can benefit from new language functions when available (perhaps operating more efficiently than user-written code could), but still work on older implementations that lack them (employing user-written functions as a fall-back).
supercat
<p>One fundamental consideration is whether the user function will override the builtin, the builtin will override the user function, or there will be no conflict.
And perhaps what happens depends on context.</p>
<p>Consider a user defined <code>div(a,b)</code> that returns <code>a divided by b</code> while handling the <code>b=0</code> case.
There are also companion functions: <code>tim(a,b)</code>, <code>plu(a,b)</code>, and <code>min(a,b)</code>.<br />
What should happen with this new definition of <code>min</code>?</p>
<p>Or functions could invoke actions by specific dogs: <code>rover(a,b)</code>, <code>fido(a,b)</code>, and <code>max(a,b)</code>.</p>
<p>Is it okay to unintentionally redefine a builtin that does something completely different?</p>
<p>Or is it okay to <em>intentionally</em> redefine a builtin to help with debugging or statistical analysis?</p>
<hr />
<p>I remember running into a problem in C, where I added <code>for(index=0;…</code> and got compiler errors.
It turned out that previously someone had helpfully put <code>#define index strchr</code> into a header file, in anticipation of the renaming of the function in the C standard.</p>
<p>And in the other direction, I once wrote a library that intercepts calls to all the section 2 functions that take filenames.
For example, my <code>open(…)</code> would check the filename to see if it began with &quot;host:&quot; and if so it would establish a connection with the other computer (where accounts with the same userid were guaranteed to be the same person).
Otherwise it would call <code>.open()</code>, with a leading &quot;.&quot;, to get the standard function from libc.
With that, anyone could reload their own programs using my library, and they would instantly get access to the remote filename mechanism, with no changes to their own code.</p>
<p>This leading dot convention was provided by the writers of libc in order both to <em>allow</em> functions to be overridden (e.g. <code>open</code> could be redefined as <code>++call_count_open; return .open(args)</code>), and to <em>prevent</em> new definitions from affecting the libc library, which made all internal calls with the leading dot.</p>
<hr />
<p>The important point here is that whatever the language does, it needs to be well defined and advertised.</p>

CC BY-SA 4.0
2023-06-20T12:53:32.427Z
2023-06-20T12:53:32.427Z
Ray Butterworth
<h3>Con: code becomes less readable</h3>
<p>Reading code, one has to look up the definitions of user-defined function, whereas build-in functionality has a constant meaning. If you allow overwriting built-in names, the reader must suspect that every built-in name has been overwritten, and must look all these up, either manually or with the help of an IDE.</p>

CC BY-SA 4.0
2023-06-20T05:17:17.080Z
2023-06-20T05:17:17.080Z
Adám
# What are the pros and cons of letting users define functions with the same name as builtin functions?
Posted by: username_0 on 2023-06-20
What are the pros and cons of allowing users to define functions with the same name as built-in functions?
For example, defining:
max(a, b) {
    if a > b return a;
    else return b;
}

as a repeat of the already existing max() function in some languages.
Or defining:
min(a, b) {
    if a > b return b;
    else return a;
}

as a repeat of min().
What are the pros and cons of letting users define functions like the ones listed above?
**Tags:** functions built-ins
> **Comments:**
> **username_1**: Relevant Meta discussion: https://languagedesign.meta.stackexchange.com/questions/370/can-i-ask-this-question  
> **username_1**: Why has the question been downvoted? It seems to be reasonable.  
> **username_2**: To be pedantic, I'd define `min` using the `<` test. E.g I can think of objects where `a>b` and `a<b` can both be true.  
> **username_3**: Is this question only for languages without namespaces/packages (for standard library functions, at least)?  
---
## 4 answers
### Answer by username_5 on 2023-06-20. Score: 14 | Accepted answer
### Pro: New builtins won't break old programs.

Perhaps the programmer wrote that `max()` function because the builtin was not available in a previous version of the programming language. If the language does not allow user functions to shadow builtins, then if the language introduces a new builtin it may break old programs that were already using that name.
> **Comments:**
> **username_6** (2023-07-17): If a language has a means of indicating "the programmer is aware that a built-in with the same name as this function may exist, and if it does it would be equally acceptable to call the built-in or this function", such a feature may allow programs to be written in ways that can benefit from new language functions when available (perhaps operating more efficiently than user-written code could), but still work on older implementations that lack them (employing user-written functions as a fall-back).  
---
### Answer by username_2 on 2023-06-20. Score: 5
One fundamental consideration is whether the user function will override the builtin, the builtin will override the user function, or there will be no conflict.
And perhaps what happens depends on context.

Consider a user defined `div(a,b)` that returns `a divided by b` while handling the `b=0` case.
There are also companion functions: `tim(a,b)`, `plu(a,b)`, and `min(a,b)`.  
What should happen with this new definition of `min`?

Or functions could invoke actions by specific dogs: `rover(a,b)`, `fido(a,b)`, and `max(a,b)`.

Is it okay to unintentionally redefine a builtin that does something completely different?

Or is it okay to *intentionally* redefine a builtin to help with debugging or statistical analysis?

---

I remember running into a problem in C, where I added `for(index=0;…` and got compiler errors.
It turned out that previously someone had helpfully put `#define index strchr` into a header file, in anticipation of the renaming of the function in the C standard.

And in the other direction, I once wrote a library that intercepts calls to all the section 2 functions that take filenames.
For example, my `open(…)` would check the filename to see if it began with "host:" and if so it would establish a connection with the other computer (where accounts with the same userid were guaranteed to be the same person).
Otherwise it would call `.open()`, with a leading ".", to get the standard function from libc.
With that, anyone could reload their own programs using my library, and they would instantly get access to the remote filename mechanism, with no changes to their own code.

This leading dot convention was provided by the writers of libc in order both to *allow* functions to be overridden (e.g. `open` could be redefined as `++call_count_open; return .open(args)`), and to *prevent* new definitions from affecting the libc library, which made all internal calls with the leading dot.

---

The important point here is that whatever the language does, it needs to be well defined and advertised.
---
### Answer by username_7 on 2023-06-20. Score: 4
### Con: code becomes less readable

Reading code, one has to look up the definitions of user-defined function, whereas build-in functionality has a constant meaning. If you allow overwriting built-in names, the reader must suspect that every built-in name has been overwritten, and must look all these up, either manually or with the help of an IDE.
---
### Answer by username_4 on 2023-06-30. Score: 1
The programmer may not be aware that some system function has been called and not a user-defined one. Even if the user-define function has a priority, this may depend on some import or header statement missing.

This is usually addressed by marking the built-in functions the way user defined functions should never be marked (`__function`, `JFunction`, `std::function` and the like), even when it makes the code more cluttered. For instance, C++ has many functions with quite common names (`tie`, `pair`, `map`) that can be easily re-invented. In some cases the code may actually compile by some chance, creating bugs that take time to find. While in old Java AWT there was a Button, in the later Swing this has been changed to JButton.
---
