You're probably right. Also, I obviously should've said, "Except the first one is much more readable to me."
I definitely don't have a problem with the Go developers keeping out random syntax additions unless they think its a really good idea.
Along the same lines, I really miss not having `map`, `reduce`, and `filter` in Go. However, it doesn't seem like those would be efficient in Go, or that they fit in with as well with systems programming, which Go was designed for. So I can't hate them for not including these.
For what it's worth, I do think it's more readable, but it's just not a good idea. It's too easy for people to inject variables into their strings and get your code to print out data that's in memory.
map, reduce, filter, etc will be easy to code up once there are generics. There will almost certainly be generics in Go at some point, that point is just not right now (and almost certainly not before 2.0).
What? There's absolutely no way for a user string to get scanned for format instructions unless you 'eval' or something like that. The proposed syntax is only for string literals in source code.
Ahh, oops, that was pointed out below as well. Sorry, I assumed a string was a string, not that this only works in string literals. That's certainly better than letter user-supplied strings work this way.
I definitely don't have a problem with the Go developers keeping out random syntax additions unless they think its a really good idea.
Along the same lines, I really miss not having `map`, `reduce`, and `filter` in Go. However, it doesn't seem like those would be efficient in Go, or that they fit in with as well with systems programming, which Go was designed for. So I can't hate them for not including these.