What are the pros and cons of letting users define functions with the same name as builtin functions?

Question

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?

Answer 1

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.

Answer 2

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 3

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 4

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.