-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFC: deprecate * in favor of new ++ concatenation operator #22461
Conversation
I am against this. @ararslan made a good comment in #11030 (comment) which I fully agree with. I teach automata theory and formal languages and in this field it is very common to use |
I don't have strong feelings, but the main advantage as I see it is that this allows us to easily extend the concatenation operation beyond string*string. |
yes but string concatenation is not the same as array concatenation. Your example with |
@tknopp This doesn't actually change the behaviour of |
Would it be reasonable to define: Base.concat_rule(::Number, ::Number) = (@_inline_meta; Array) ? |
I know, but this also implies that one really should not use |
@iamed2, |
I am very much against this. My specific objections:
|
Besides the usual arguments against this change that were written a hundred times, which I won't repeat here, I'm not convinced by the pro's at all:
(Please don't take the last two points too seriously. What I'm arguing is that Also, more (minor) cons: we lose |
That could be an argument in favor of using Regarding |
I've been skeptical of the need for a renamed string-concatenation operator, but arguments about this have been going on for years, and
Personally, my conclusion from this experiment is that it's probably not worth it. None of the string code seems to be much improved by this change, and the elimination of However, I would be in favor of defining |
I don't think the main arguments in favor of deprecating Anyway no discussion will solve this, somebody just needs to make a decision. |
Where is the issue? For numbers and matrices |
@tknopp I'll just point to arguments @StefanKarpinski gave in the other issue here and here. It's true that multiplication has very different meanings for numbers and matrices, but at least there's a very strong tradition of calling these operations "multiplication". That's not the case for strings. (Let's not repeat this discussion, which has already happened in #1130 AFAICT.) |
sure, I will be quiet. But bringing such a PR on the table is a proactive action to get this change in. So whats the way to argument against a PR if discussions are just allowed in #1130? |
Sorry, I didn't want to imply that comments are prohibited on this PR, I was just feeling guilty of reviving the same discussion again. If you have new arguments, by all means give them. |
We can't use 🐈? I'm sure that would make @ararslan happy. |
[noise](if this gets merged, my only public, solo-authored package is never going to take off as I had expected https://github.com/pkofod/PlusPlus.jl )[/noise] |
Whatever happens to this, when it happens #11030 should be closed. |
Given that consensus seems to be against this change, and indeed the author of this PR himself does not support the change, plus we now have |
Completely separately to strings, it's my feeling that having a general concatenation operator and naming it The consequence of doing that though is that Anyway, that's my opinion for the record but I won't stand in the way of closing this. |
Strings shouldn't be conflated with arrays, which is why it makes sense to separate general iterable concatenation from string concatenation. |
|
Sequence concatenation doesn't really make sense for matrices anyway. I guess if you want to iterate one after the other you can do |
@ararslan Iteration is the basic interface I'm talking about here... we don't want |
@andyferris |
Triage thinks we should consider |
Thanks for doing the science here, @stevengj. Feels good to finally have this settled. :) |
As discussed in #11030, this PR deprecates
*
in favor of a new all-purpose concatenation operator++
. (++
has been parsed as a binary operator since Julia 0.5, so Compat support shouldn't be a problem.)a ++ b
defaults tovcat
, and since++
is chaining you getvcat(a,b,c)
froma++b++c
. However, there is a generalBase.concat_rule
mechanism (analogous topromote_rule
) that can be used to customize concatenation. Concatenation of anAbstractString
with anything that is not an array callsstring
, e.g."foo" ++ '-' ++ "bar" ++ 3
produces"foo-bar3"
, but"foo" ++ [1]
produces["foo", 1]
.string^n
is deprecated in favor ofrepeat(string,n)
.Also, I lowered the precedence of
++
. Previously, it was the same precedence as+
, but that seems wrong for concatenation. You wanta ++ 1:n
to parse asa ++ (1:n)
, not(a++1):n
. Hence, this is technically a breaking change, but I doubt that anyone is affected.Pro:
++
eliminates the type-pun with*
(see alsoone
for AbstractString #19536), and gives us an explicit operator dedicated only to concatenation. It is already much more general than*
for strings (e.g.string++char
works), and it is more easily extensible if we want to supportchar ++ char == string
, for example, or define++
for concatenation ofSet
,Dict
, and the like. When optimizing code, it makes it easy to search for instances of repeated concatenation (since this tends to be inefficient).Con: Will cause a lot of code churn (witness the size of this PR).
To do:
Set
?The basic question here is whether people like this overall approach:
++
as a general concatenation operator (not just strings), with aconcat_rule
mechanism to decide on the resulting container. (One issue withconcat_rule
is that the resulting concatenation may not be associative, i.e.a ++ b ++ c
may be different froma ++ (b ++ c)
.)cc: @StefanKarpinski