any2stringadd implicit should be removed from Predef

[scabug]

This implicit removes too much type safety, and can lead to confusing results.

I think this is more important than the '+' operator being symmetric.

UPDATE 2015-07-29:
Workaround: You can opt-out on a per-file basis by unimporting it.

import Predef.{any2stringadd => _,_}
object foo extends App{
  println(new java.util.Date + " sfsdf") // error: value + is not a member of java.util.Date
}

[scabug]

Imported From: https://issues.scala-lang.org/browse/SI-194?orig=1
Reporter: @propensive
See #6806, #1931

[scabug]

@odersky said:
I disagree on this point. I believe `+' should work as in Java. For a long time we did not have any2stringadd and it was a constant pain, in particular for programmers recently converting from Java.

[scabug]

@odersky said:
Milestone 2.6.1 deleted

[scabug]

Eugene Yokota (eed3si9n) said:
Having continuity with Java is great, but not at the price of compromising type safety.
A good example is the use of null vs Option[A].
As a programmer get situated in Scala comfortably, he or she no longer thinks in terms of Java or other languages,
and a normal Scala would almost never use null actively (with a few exception in standard lib such as regex extraction and XML namespace).
In my opinion, having a source-level compatibility of + with Java doesn't buy much, and is very harmful to Scala as a language. More than once I've been bitten by unintended "Some(...)" or "None" showing up in string output.
An ideal course of action would be to deprecate any2stringadd so the compiler would start raising warnings, if not an optional compiler error would be helpful like -no-unsafeadd.

[scabug]

Heikki Vesalainen (hvesalai) said:
There should at least be a way to turn this implicit off.

[scabug]

@SethTisue said:
Now that Scala has string interpolation, there is less need to build strings with +. So perhaps this decision could be revisited.

[scabug]

@Sciss said:
Constant pain point for DSLs and confusing many people. E.g. http://stackoverflow.com/questions/20800102/on-a-vector-gives-strange-wrong-type-errors . Should be re-opened I think.

[scabug]

Kevin Wright (kev.lee.wright) said:
+1 for re-opening

[scabug]

Heikki Vesalainen (hvesalai) said:
This issue should really be re-evaluated and discussed properly.

[scabug]

@soc said:
We should at least consider a standardized way for people to opt-out of this madness via a language import.

[scabug]

Kevin Wright (kev.lee.wright) said:
Is it worth considering a language import for Java source-compatibility in general?
No doubt there are other language features added for familiarity to Java developers, which now look "quaint" in retrospect.

[scabug]

Rich Oliver (rich oliver) said:
I actually find this can be particularly confusing when teaching complete beginners and introducing basic types, not to mention the weird errors about strings that appear out of nowhere when you have been near a string. 2 + "two" is wrong. It certainly shouldn't equal "2two".

Println etc can now be implemented as macros for ease of use. So there's even less justification for polluting the whole of the global name-space.

[scabug]

Alexandru Nedelcu (alex_ndc) said:
I think it's worth pointing out that this behavior is not common in many mainstream languages.

Here's Python:

>>> "" + 2
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: cannot concatenate 'str' and 'int' objects

Here's Ruby:

irb(main):001:0> "" + 2
TypeError: can't convert Fixnum into String
	from (irb):1:in `+'
	from (irb):1
	from /usr/bin/irb:12:in `<main>'

And in languages where it is, it's given as a bad example. I think Java folks can learn to appreciate a lack of implicit conversion to string, especially given that they don't need it with string interpolation.

[scabug]

Matthew Pocock (drdozer) said:
I feel that the rational for this ease of use is now much lessened by string interpolation. It is very easy to write f"$a $b" and it's crystal clear that we're doing stringy things so a+b as a shorthand now feels redundant.

What else needs tackling related to this? Perhaps we need to grep the stdlib for all def + (_: String): String declarations? For binary compatibility, can they be annotated @bridge for one release cycle, or is that for something else?

[scabug]

@adriaanm said:
Here's a crazy idea: how about deprecating any2stringadd, and making implicit search ignore deprecated implicits under -Xfuture.