-
-
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
Taking string concatenation seriously, or, a proposal to deprecate *, ^ for string concatenation and repetition #11030
Comments
+1 for no infix operators at all. This subject attracts too much noise, and O(n) for If there is discussion about alternatives, then +100 for moving it to the |
+1 to that |
😆 |
LOL. +1 on the (I'll personally feel sad to see this use of |
Stefan recently gave a nice, succinct explanation for why he wants to see them go, I'm going to quote it here:
|
I for one agree that |
I didn't see this before unleashing a rant on the unsuspecting lastest derailed mailing list thread, where I suggested |
I really think you should avoid using anything that already has a meaning (other than string concatenation) in other major languages in the world.
I'd vote for ++, it is used for concatenation in a reasonably popular language, i.e. Haskell, |
I don't think
If we're going to have a string concatenation operator, I'd rather it just be a string concatenation operator and nothing else. (Has anyone complained about the lack of an infix operator for other sequence concatenation operations?) I'm also fine with not having a string concatenation operator, but the presence of such an operator in most other languages makes me wonder if I'd miss it if I were doing more string-heavy projects like web stuff. I'm fine with not having an infix operator if we decide we don't need it because interpolation tends to be more useful than concatenation, but if it's because numerical workflows don't do too much concatenation, I'd think twice. |
Whether there should be a replacement is a decision that can be deferred. For once, can we keep a string concatenation-related issue narrowly defined? |
If we're going to introduce a replacement, I think it makes the most sense to deprecate |
@StefanKarpinski you'd also get the nice behavior of @simonstr, it makes sense to me, as somebody who spents most of their time with string processing...
(if you combine a Vector with a string, (which is immutable), you'd much rather get back another mutable vector, you can always convert it to an immutable string with UTF8String later) |
Then this issue will devolve into every other discussion about this ever. The community has already established that it is unable to handle the topic. It's the ultimate bikeshed and there are a lot of colors to choose from. If I sound irritated by this, it's because I am. Here's my experience. "Hey, you can't glue strings together with So no, I don't think we should discuss alternative infix operators in this issue, because we'll never make progress if we do. |
Obviously a NaN: |
To voice my opinion on the matter, I have used languages whose string concatenation operator was
Where promote promotes an appropriate container type. The last option would imply
|
@Keno, I that's not correct, because 'a' is Char, a 32-bit type. |
I vote for ++ |
Actually, if you have a ASCIIString, it could promote to just UInt8[], but a UTF8String (as well as UTF16String and UTF32String) would need to promote to Char[]. |
(and that sort of promotion would be very useful for my string processing...) |
This issue could be titled "Taking string concatenation seriously". |
I'll just note that:
so no, |
Please let's not subject ourselves to 200+ comments before we feel like it's been taken seriously enough. Can someone just make a PR? I think everyone is in favor of deprecating *, ^ (if only to remove the mailing list bug). The ++ operator seems to be getting decent traction, but it's obviously tricky and not obvious to make it general. There are tricky semantics (similar to |
@ScottPJones Sure, I was writing it that way for illustrative purposes, since |
LOL. |
I think I'd want one, but can I get it with Okay, sorry. Continuing the injokes is fun, but let's stay focused. Let's try to come up with a bare minimum set of features that a PR could reasonably implement:
Anything that generalizes to other containers I think we can hash out inside the PR. |
I want one with ++! 😀 |
@staticfloat 💯 👍 |
@PallHaraldsson The problem there is that both
is it a good (or bad) idea to exclude the numbers - that are already handled: julia> print("Páll", 1.0, 1)
Páll1.01
julia> string("Páll", 1.0, 1)
"Páll1.01" |
@ScottPJones, unfortunately quoting doesn't seem to work when responding by print("Hi GitHub! Is this quoted") @PallHaraldsson, do be careful how you write someone's name, though. You In either case, using the GitHub interface, rather than replying by email, On Sat, Jun 13, 2015 at 5:24 AM, Scott P. Jones notifications@github.com
|
Ugh... I didn't know that @PallHaraldsson was responding via e-mail, nor that e-mail had that problem (I use the CodeHub app when I'm not at my laptop... it has it's own problems, but not that). |
LOL, yes, this was confusing! I’ve met “myself" a few times over the years, so this is not the first time that this kind of confusion has happened. :) Cheers, -Scott On Jun 13, 2015, at 11:37 AM, Scott P. Jones <notifications@github.commailto:notifications@github.com> wrote: Ugh... I didn't know that @PallHaraldssonhttps://github.com/PallHaraldsson was responding via e-mail, nor that e-mail had that problem (I use the CodeHub app when I'm not at my laptop... it has it's own problems, but not that). — |
For what it's worth I actually really like |
I think we should just keep |
We may add |
I would keep This is what Wikipedia says about regular expressions as algebraic operations:
In linear algebra, there is a unary operator, the adjoint operator, often denoted by |
As @stevengj pointed out, the argument between Then the main reason I could think about keeping |
Nothing would break and if you really want it you can define |
I propose using
We could use |
@ StefanKarpinski (1) If
No, string repetition (whatever operator it is) is not a frequent operation to me. But string concatenation is. If this is a general case, it seems replacing repetition operator with a named function (eg. And I realized creating new operators is really a disputable/dangerous thing, while supporting more APIs is usually welcome:) Edit: Found another thread that introduced |
Rationale: even though JuliaLang#11030 was closed, there is discussion of the issue from time to time on Github and the forum; so if any question is frequently asked, this is.
Rationale: even though JuliaLang#11030 was closed, there is discussion of the issue from time to time on Github and the forum; so if any question is frequently asked, this is.
What? This long discussion, and nobody suggests the obvious 🐈 operator? |
The frequency and vehemency of discussions around this subject beg for a change.
*
and^
were introduced for strings back when the language wasn't as strict on operator punning and overall meaning.As a first, step, I propose we deprecate these two methods for string operations.
As a next discussion, we can talk about the possibility of using a different operator(s) for concatenation/repetition. Just using
repeat
, with no operator, has been suggested, as well as the following for string concatenation:++
, as a general sequence concatenation operator..
, similar to LuaThings to consider:
vcat
/hcat
?The text was updated successfully, but these errors were encountered: