4 ms·
> 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 a
by 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.