3 ms·
Is this something Go intentionally didn't add?
by gcau 2y ago
Is this something Go intentionally didn't add?
- sbhitz 2y agohttps://go.dev/doc/faq#overloading https://go.dev/doc/faq#overloading
- jagged-chisel 2y agoYes. Because "things are simpler without it." Presumably "simpler" from the point of view of the language implementer as opposed to the user of the language.
- abtinf 2y agoOperator overloading essentially makes code unreadable without deep diving past the interface boundary. In Go, you can generally look at any snippet of code and know precisely what it does.
- dsfasfd 2y agoNot having operator overload making the code more readable is the same argument that was brought up with generics and it is still false. Go does have operator overloading, for example + is overloaded for float.., int.. and even non numeric types like string. And it does so for a very good reason: having operator overloading makes code much more readable when used correctly. It's just that the language designers didn't trust their users. As long as you know the types of x and y you always know precisely what x + y does, same as you know what x.Add(y) does. There's no difference.
- vincentkriek 2y agoThere is no difference to a .Add() function, that's true but even for strings you wouldn't have an Add function. It would be an Append() most likely which explains much more what is happening. And verbosity helps, forcing users verbosity helps the general level of quality. Programmers could overestimate themselves and think they are doing it correctly. Looking back in my code from a year ago I see things I should have done differently. I like languages that avoid me making real dumb mistakes
- xigoi 2y agoHow is a + b any less “know precisely what it does” than a.add(b)? It’s literally just different syntax for the same thing.
- deleted 2y ago[deleted]