Just a note, Matlab-style [a b] concatenation has been deprecated in Julia v0.4 <https://github.com/JuliaLang/julia/pull/7998>. See the linked issues for details. The main issue is that this functionality makes it challenging to create arrays of arrays (or arrays of ranges), which are less useful in Matlab, but quite useful for general programming.
Aside: a colleague who was a pretty proficient perl programmer found it quite confusing that "+" was used for string concatenation in Python, because he couldn't understand how you could add two strings... Cheers! Kevin On Mon, Apr 27, 2015 at 7:16 AM, Scott Jones <[email protected]> wrote: > Changing to + would still run into the problems where you are using > vectors of UInt8, UInt16, UInt32 (or Char), for mutable strings. > Not good either. > > Add [] for general concatenation, (i.e. like vcat on vectors/arrays), and > and add a compiler warning for * suggestion replacing with [], and remove * > for strings by 1.0. > (Add something else (maybe !*, or does MatLab or some other language have > a repetition operator that is not overloading some numeric meaning?) for > general repetition of strings/vectors, and do the same with warnings for ^ > and removal by 1.0). > > It seems to me, that the people who don't use or care that much about > strings, are the ones who say, just use string() or repeat(), no need for a > *good* non-confusable > infix operator... and the people who really do work a lot with strings > want this changed ASAP. ;-) > > On Monday, April 27, 2015 at 9:51:56 AM UTC-4, François Fayard wrote: >> >> I have no idea how much it would cost too change * to + for string >> concatenation. That's where you value tools such as clang-modernize on C++ >> or corresponding tools on Go. Perhaps the best way to get rid of it is to >> enforce the change. >> >> Maybe allowing + and * for a few iterations, and removing * before 1.0. >> Then you won't hear about it anymore. Otherwise, people will rightly >> complain about it for a long time. >> >> I guess that the fix itself is trivial (simply remove the method >>> definition or change its name), but the associated costs may not be >>> (breaking code), and from the discussion in the issues it looks like the >>> decision has not been made yet. >>> >>> Again, I do think that * and ^ for strings is not an ideal choice, but I >>> am still surprised how often this issue crops up and how strongly people >>> feel about these infix ops. Its not like one has to use them, if you >>> don't like * or ^ for strings, there are `string` and `repeat` and a few >>> other alternatives which may be more suitable in certain cases. This is >>> what I do at the moment. >>> >>> Perhaps limiting the number of discussion threads about >>> *(s::AbstractString...) to 1/month would not be a bad idea :P >>> >>> Best, >>> >>> Tamas >>> >>
