Deprecate /: and :\ as symbolic aliases for foldLeft and foldRight

[scabug]

See http://scala-lang.org/blog/2016/01/02/new-year-resolutions.html.

Another example, where I have doubts if not regrets are the /: and :\ operators in scala.collections. They are cute synonyms for folds, and I am still fond of the analogy with falling dominoes they evoke. But in retrospect I think maybe they did give a bad example for others to go overboard with symbolic operators.

[scabug]

Imported From: https://issues.scala-lang.org/browse/SI-9607?orig=1
Reporter: @soc
Affected Versions: 2.12.0-M3

[scabug]

@SethTisue said:
Simon's PR on this is scala/scala#4893

[scabug]

@szeiger said:
Result of team meeting discussion: Don't deprecate at the moment. This should be an Abide rule instead.

[scabug]

@SethTisue said:
I think we should consider documenting that the methods are primarily historical and not really recommended, even if they don't end up actually deprecated.

[scabug]

Naftoli Gugenheim (naftoligug) said:
What meeting? What was the discussion?

[scabug]

@soc said (edited on Jan 20, 2016 9:13:18 AM UTC):
Yes, I assumed that the time of meetings behind closed doors were a thing of the past.

While I think that the idea of abide is great, I don't think it should disrupt maintenance of core libraries, especially when it neither has a stable release nor ships with Scala yet.

[scabug]

@SethTisue said:
Simon, the Scala team at Typesafe meets often and talks to each other pretty much constantly, like any software team. We're not issuing ultimate rulings — just talking to each other. There are no more big all-hands-on "Scala meetings" anymore, like there used to be at EPFL — precisely because so much of the discussion and decisionmaking is now happening on GitHub, on Gitter, on JIRA, via SIPs and SLIPs, and so forth.

To go into a bit more detail about the discussion at the meeting, Jason's feeling was that even if we wish we could go back in time and prevent /: and :\ from ever having existed, deprecating them now doesn't actually accomplish that, and just creates inconvenience for those already using the methods in their code. Simply documenting that we no longer recommend actually using the methods — with the expectation that linter authors may choose to follow along with linter rules — seems like a reasonable middle ground. 2.12 isn't primarily a library release anyway, like 2.13 is projected to be (http://www.scala-lang.org/news/roadmap-next/), and since nothing else depends on these methods, there's no urgency about deprecation in 2.12. The deprecations we're most interested in for 2.12 are ones that open a door towards a future desired change.

Honestly, personally, I still lean towards deprecating anyway. I find the continued existence of these methods irritating. But my feeling about it isn't strong enough to try and force the issue — it's not that big a deal.

[scabug]

@soc said (edited on Jan 21, 2016 8:27:21 AM UTC):
The point about deprecating it for 2.12 is that we can figure out whether we want to keep or remove it in 2.13, considering that there is a lot of documentation out there which might need to be corrected (checked SO and a few other places) and considering that developers can make the adjustments and be compatible with 2.11.

Due to some botched deprecations in 2.11 we have a huge backlog of cleanups already, in addition to all the changes we are not doing in 2.12 to keep the gap between 2.11 and 2.12 reasonably small. I'm pretty sure that kicking the ball further down the line won't make things easier. The idea about linters is nice, but just with abide, if there is no committed shipping date, this is not something we should or can rely on. (Ignoring the issue that it's yet another tool developers have to be aware of.)

I would appreciate if discussion could find their way back to internals in the future.

[scabug]

Naftoli Gugenheim (naftoligug) said:
Perhaps the question should be discussed on scala-debate?

[scabug]

@soc said:
Can someone with PinS3 comment whether these methods are still mentioned in the book?

[eed3si9n]

@SethTisue Is resurrecting scala/scala#4893 a good first issue?
Looks so easy maybe I can do it.

[SethTisue]

@eed3si9n yeah