"My name is " + name + " and surname is " + surname
or this:
fmt.Println("My name is %s and surname is %s", name, surname)
Except the first one is much more readable.
String interpolation seems like a small thing, but I find myself wanting to use it all the time. It's definitely not a "magic" feature. Javascript really needs it as well.
I disagree, especially in the presence of syntax highlighting editors.
String interpolation would be a redundant alternative to existing mechanisms (the above plus text/template for longer strings) and just make parsing more complex. I don't think it would fit in well with Go's philosophy of providing pleasant, minimalistic syntax.
I find that there are some disturbing similarities between the Java community and the Go community when it comes to features and culture. There seems to be an unwritten assumption that the language is perfect in its current form and any additional features are a source of evil (up until the day when they are added, in which case they are suddenly evidence of the language's superiority).
It works really well in its current form, that is probably the general consensous.
> additional features are a source of evil
Some of us have walked down that path before (e.g. Perl, Scala) and think we have seen the light (or at least the darkness).
> up until the day when they are added, in which case they are suddenly evidence of the language's superiority
That sounded very much like flamebait. Could you name an example of a feature added to Go that was previously considered evil and then as evidence of Go's superiority?
Thescrewdriver is absolutely correct about Java. Many years ago, I participated in several Java user groups here in Silicon Valley. We frequently had members of the Java team from Sun as guest speakers. It always went roughly the same: we professional Java devs would ask them for a few language features that most of us wanted, and they would explain to us that they knew better than we did what a programming language should have and suggest that we should get over it.
Then a representative from Microsoft started attending a couple of the biggest Java SIGs, and he would ask us how we would change Java if we could. We were happy to answer. A few of the suggestions were broadly desired by the groups.
He took lots of notes, and a year or so later C# was announced. It included several of those features. My impression is that most of us considered it a better Java, as a language design. (The Achilles Heel of its relationship to Microsoft was a huge, but separate, issue from the design of the language itself.)
The Java Team suddenly had a whole new attitude about their fossilized masterpiece, and features we had been told for years were bad ideas were touted as evidence of Java's ongoing spirit of innovation with each new version of Java.
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.
What do you mean by being easier to internationalize? Do you mean you can lookup the string at runtime and it will then interpolate on that? That's not a safe way for interpolation to work, because then random strings from unsafe sources can start including any variables from your environment. String interpolation should only apply to string literals. What you actually want (no idea if it's available in Go) is something akin to Sprintf but with named instead of positional arguments, and then explicitly provide a map of those arguments rather than letting it get them from the lexical environment as interpolation does.
You have made the assumption that the values provided just come from the enclosing scopes. The various packages I found all require an explicit map/dictionary passed in - ie there is nothing unsafe - only named values intended for formatting can be used. (The OP likely didn't show the map/dict because that wasn't relevant to their point.)
String interpolation is wrong in a world where there are so many variants of escaping strings. It is not useful for templating HTML, SQL, CSV, JSON, XML.
This only leaves us console programs and backdoors. I'm happy to give these two up for a stronger language.
String interpolation is magic because it's not entirely obvious when it happens, what scope rules are followed, if there are any side effects, if the original string is overwritten or whether a new instance is created, what happens when they are used within bodies of loops, what happens when they are used within closures etc., it just works. Sure these can be specified explicitly but they aren't obvious.
It's the kind of feature that is useful when you write an application but not that useful when you're trying to debug it.
I can understand if you don't like the syntax of string interpolation, but that argument is a cop-out.
If you're genuinely confused by it's behaviour then I'd suggest steering clear of the Printf (and even the vanilla Print/Println functions which does concatenation and automatic type conversion).
Or perhaps, a better suggestion would be to read the language specs and learn interpolation's behaviour since this "magic" is almost always well documented [hint: it's actually less complicated than Printf ;)]
> It's the kind of feature that is useful when you write an application but not that useful when you're trying to debug it.
It's largely used in log messages and the like where it's used for debugging issues after the fact. I've yet to encounter a case where anyone was ever confused by the behaviour.
Right, if this gets in then I officially demand that the much more innocent ternary operator and prefix/postfix increment/decrement operators get in as well.
If I had to choose, I'd pick string interpolation.
i += 1 means an extra line, but that extra line is very clear.
Ternary vs an if-else arguably loses on clarity except for the simplest of cases.
"Today's date is #{date}. Your balance on account #{account.Number} is #{account.Balance}"
"Today's date is " + date + " Your balance on account " + account.Number + " is " + account.Balance
The second is a mess of +'s and "'s to me, not to mention the awkwardness of formatting spaces before and after each quote. The first, you write a sentence and plug in the variables where they belong.
Not saying you're wrong, just what I would choose.
Uh, grabbing variables out of the current scope to format your string is most certainly magical. It's also way less explicit than actually passing variables into a formatting function.
It might be a little harder to read, but that's a lot different than explicit.
fmt.Sprintf("Hello %s!", username) is very explicitly using the username variable from the local scope, and nothing but the username variable can ever get included in the output string. At most, a user could put a %s in their string, and get the username to appear somewhere else in the output... but they wouldn't be revealing data that wasn't already intended to be printed out.
In comparison, interpolation is opening a door to let anyone extract whatever variables happen to be in scope at the time by putting #{password} or #{secret_key} in their string. By moving the definition of what variables get printed out into the data, you're opening a really big hole in your code... it also makes it a lot harder for the compiler to check for correctness.
A language like Ruby will only perform interpolation on string literals, so there isn't a way (that I know of) for data to inject interpolated strings.
I guess that's my lack of knowledge of how Ruby's string interpolation works. I assumed it worked like any old string format, which in other languages can use whatever string is passed into the formatting function. It sounds like that's not the case for Ruby's string interpolation. My apologies for jumping to conclusions. I guess it's my statically compiled mindset that assumes a string is a string.
You can kind of think of it as syntactic sugar over adding strings that desugars at the compilation stage.
"abc #{x} def" would desugar to "abc"+x+"def"
Because it's happening at the compilation stage, it can only be done on string literals (which as we've seen is actually an advantage security wise).
The reality is actually a tad more complicated, because you can make efficiency improvements and only create one string instead of all the intermediate strings etc. but the effect is the same.
