3 ms·

One of the main drawbacks of function overloading is that it can make code harder to read and understand. When the same function name is used for multiple diffe

One of the main drawbacks of function overloading is that it can make code harder to read and understand. When the same function name is used for multiple different purposes, it is confusing for developers who are reading the code. This makes it more difficult to maintain and modify the code in the future, as developers spend extra time trying to understand the various function definitions and how they are being used. Even finding what file the function is in can be a non-trivial task. Another issue with function overloading is that it can make code more difficult to debug. If a bug is found in one of the overloaded functions, it can be difficult to determine which function is causing the issue. This can make it more time-consuming to fix the bug and can lead to frustration for the developer. I remember debugging an issue at OkCupid and we lost many hours due to debug information being collapsed for overloads, making it look like the wrong function was being called in the debugger. Finally, function overloading can lead to code that is more prone to errors. When the same function name is used for multiple different purposes, it can be easy to accidentally call the wrong function with the wrong arguments, which can lead to unintended consequences or runtime errors. In conclusion, good riddance. This is what makes Zig a great language, that it doesn't have garbage like function overloading.

elcritch 4y ago
> it is confusing for developers who are reading the code. … as developers spend extra time trying to understand the various function definitions and how they are being used. This is a similar argument to Hungarian encoding, IMHO. A decent LSP makes it trivial to see which function is being called. The other issue you mention is a problem with the debugger/compiler, not function overloading. > Even finding what file the function is in can be a non-trivial task. Not really, control-click and you’re at the function def. > it can be difficult to determine which function is causing the issue. This can make it more time-consuming to fix the bug and can lead to frustration for the developer. Not any harder than “method” overloads, which it sounds like Zig does have. Personally I find the opposite. Having 20 names for functions that all equate to `len` requires more mental overhead.
- vkoskiv 4y ago
  > A decent LSP makes it trivial to see which function is being called. We're talking about replacing C here. Requiring everyone depend on a hefty LSP to make sense of source code is a big ask. Source code is text. I firmly believe that all semantic information of a piece of source code should be expressed as text in said piece of code. I already see code where the language allows the programmer to omit types from variables for 'brevity', and the assumption then is that everyone working on that code is using a fancy enough text editor that can stick in extra labels to show the missing type information. Absolutely baffling to me how people find that acceptable in any way.

elcritch 4y ago

> it is confusing for developers who are reading the code. … as developers spend extra time trying to understand the various function definitions and how they are being used. This is a similar argument to Hungarian encoding, IMHO. A decent LSP makes it trivial to see which function is being called. The other issue you mention is a problem with the debugger/compiler, not function overloading. > Even finding what file the function is in can be a non-trivial task. Not really, control-click and you’re at the function def. > it can be difficult to determine which function is causing the issue. This can make it more time-consuming to fix the bug and can lead to frustration for the developer. Not any harder than “method” overloads, which it sounds like Zig does have. Personally I find the opposite. Having 20 names for functions that all equate to `len` requires more mental overhead.

vkoskiv 4y ago
> A decent LSP makes it trivial to see which function is being called. We're talking about replacing C here. Requiring everyone depend on a hefty LSP to make sense of source code is a big ask. Source code is text. I firmly believe that all semantic information of a piece of source code should be expressed as text in said piece of code. I already see code where the language allows the programmer to omit types from variables for 'brevity', and the assumption then is that everyone working on that code is using a fancy enough text editor that can stick in extra labels to show the missing type information. Absolutely baffling to me how people find that acceptable in any way.