3 ms·
No, if conversion is implicit you don't have to think which function to call, where to find it and which library to include. Quite significant cognitive overhea
by zzzcpan 12y ago
No, if conversion is implicit you don't have to think which function to call, where to find it and which library to include. Quite significant cognitive overhead I'd say.
Having separate concatenation operator with implicit conversion could reduce that overhead:
a := "foo" ~ "bar" ~ 123
Instead of:
import "strconv"
a := "foo" + "bar" + strconv.Itoa(123)
But this is not how Golang guys make decisions. And I'm fine with that nowadays as long as they don't claim to be right in that regard.
- dbaupp 12y agoThe interesting code for this example is: c := a + b There's no indication from that line of code what a and b are, a type system that doesn't do implicit conversions will tell you "error: adding string and int" and so the programmer can address the problem (e.g. maybe they meant to parse an integer from the string `a`, maybe they meant to format the integer `b` into a string). Using literals is not a useful comparison because there is no confusion about types in that case.
- zzzcpan 12y agoMy bad, I thought it was obvious from having separate operator for concatenation that '+' operator also has only one intent. So in your case it will parse an integer from a string if operand is a string.