Julia: rename `string` to `strcat`

[StefanKarpinski]

Since what it actually does is convert things to strings and concatenate them. People have a lot of confusion around this name and the similarity to String. I think renaming it to strcat would alleviate a lot of that confusion pretty quickly. I'm not set on the exact name strcat but have opened this issue as a place for some discussion and bikeshedding.

[nalimilan]

One advantage of this would be to merge join with strcat, which would be more explicit and would free the join name for database-like operations (e.g. DataFrames and JuliaDB use it).

We may want to keep the one-argument string method (and define strcat in terms of string), since calling strcat on a single argument would look funny. That method would accept formatting keyword arguments (like base and pad for integers), while strcat would not.

[davidanthoff]

Couldn’t String just always work for the one argument cases?

[stevengj]

I'm not sure how you would merge this with join, unless you want to deprecate join to splatting?

[nalimilan]

I was just thinking about a special method with the same signature as join, maybe with keyword arguments for delim and last to avoid possible ambiguities (I find them more appropriate in that case anyway).

[JeffBezanson]

The problem with String is that it accepts arguments tailored to the specifics of constructing an instance of that type, e.g.

julia> String([0x41])
"A"

julia> string([0x41])
"UInt8[0x41]"

A secondary possible issue is that String should only return objects of that type, but conceivably string(x) might want to return a different kind of string for some objects.

[davidanthoff]

Ok... I can just report from the field, that even after 4 (5?) years of heavy julia use I'm always confused which of these two I should use when... Don't want to side track this issue here, but if this was an opportunity to simplify this, it would be great.

[bramtayl]

What about paste alla R?

[JeffBezanson]

I find that a bit surprising, because String and string (despite the admittedly absurdly-similar names) have very little overlap. string gives you a string representation of anything, while String has few methods and is only used in particular situations like interpreting a byte vector as a utf-8 string.

[ararslan]

strcat seems misleading, since concatenating strings is just one thing that string does. It's effectively sprint(print, x), except that it can print numbers in a base. If anything, I think we should just use sprint(x) for this.

[samoconnor]

julia> x = [0x41]
julia> eval(parse(string(x))) == x
true

What is a good word for the opposite of parse?
What about codestring or juliastring or encode

julia> eval(parse(codestring(x))) == x
julia> eval(parse(juliastring(x))) == x
julia> eval(parse(encode(x))) == x

[JeffBezanson]

The opposite of parse is closer to repr.

[GunnarFarneback]

So string makes strings out of things, and if asked to do so for several things, it concatenates the strings?

This scores very low on my personal surprise-meter. In fact no detection at all.

[nalimilan]

Do opponents have an alternative proposal to free join for database operations? That's actually the issue which started this.

[stevengj]

I was just thinking about a special method with the same signature as join

@nalimilan, I don't see a workable proposal to eliminate join here. The behavior of the two functions is completely different on the same argument type:

julia> string(["a","b","c"])
"String[\"a\", \"b\", \"c\"]"

julia> join(["a","b","c"])
"abc"

If you want to leave string alone and rename join to strcat, that would be a separate PR.

[nalimilan]

I my mind, strcat wouldn't have accepted single arguments since that's not a concatenation. I agree it's not great, though, since that would introduce a special case. Another solution would be to enable the join behavior via a keyword argument.

If we keep a different function, strcat wouldn't be the best name if it didn't accept varargs (for consistency with cat). Other possible names: paste (as in R), flatten (would accept other types, like Iterators.flatten, but non-lazy), collapse, implode (as in PHP)... Or maybe join isn't so bad after all, given that the confusion with databases is really limited and that it's the term used by Python, Java, JavaScript and .NET.