Looks like a good solution to me.
On Monday, April 27, 2015 at 4:16:19 PM UTC+2, Scott Jones 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 >>> >>
