the fate of ++:

+1
On 26 May 2010 17:01, Paul Phillips <paulp@improving.org> wrote:

Trying to iron out another inconsistency in collections.

Method ++: was in 2.7 and only on various Buffers, and was deprecated
before I got involved.  So now it sits alone on BufferLike, deprecated
and acting inconsistently with its name (in that it modifies the target
instead of creating a new collection.) If it's supposed to be deprecated
I don't want to @migration it, and anyway we still need to fix the
compiler to use both those at once.

Simplest and possibly best solution if we're up for one more method on
Traversable: define it as the dual of ++ on Traversable, have it create
a new collection, and switch BufferLike to a @migration annotation for
creating a new collection.

Or, your idea here.

--
Paul Phillips      | It's better to have gloved and tossed than never to
Imperfectionist    | have played baseball.
Empiricist         |
ha! spill, pupil   |----------* http://www.improving.org/paulp/ *----------

--
Kevin Wright

mail/google talk: kev.lee.wright@googlemail.com
wave: kev.lee.wright@googlewave.com
skype: kev.lee.wright
twitter: @thecoda

Hi,

I was just answering on trac on this issue.
I missed the point about `++:` being deprecated because it is not
supposed to be there.

I agree with you that adding migration to it should not be done in this
case, since there is no corresponding `++:` method in the Traversable.

However, I vote to add `++:` to Seq then. Otherwise, it behaves no
different than `++` for Maps and Sets, and differently for `Seq`.
Besides, since there are methods like `+:` in Seq, people might start
requesting that we move `+:` to Traversable too.

If we decide to do so, the question is whether this goes to RC3 or not.

Cheers,
Alex

On 26/05/10 18:01, Paul Phillips wrote:
> Trying to iron out another inconsistency in collections.
>
> Method ++: was in 2.7 and only on various Buffers, and was deprecated
> before I got involved. So now it sits alone on BufferLike, deprecated
> and acting inconsistently with its name (in that it modifies the target
> instead of creating a new collection.) If it's supposed to be deprecated
> I don't want to @migration it, and anyway we still need to fix the
> compiler to use both those at once.
>
> Simplest and possibly best solution if we're up for one more method on
> Traversable: define it as the dual of ++ on Traversable, have it create
> a new collection, and switch BufferLike to a @migration annotation for
> creating a new collection.
>
> Or, your idea here.
>

On Wed, May 26, 2010 at 06:27:26PM +0200, Aleksandar Prokopec wrote:
> However, I vote to add `++:` to Seq then. Otherwise, it behaves no
> different than `++` for Maps and Sets, and differently for `Seq`.

No, not true. The result type of ++: would be dictated by the right
hand side instead of the left hand side.

scala> Set((1, 2)) ++ Seq((3, 4))
res1: scala.collection.immutable.Set[(Int, Int)] = Set((1,2), (3,4))

scala> Seq((3, 4)) ++ Set((1, 2))
res2: Seq[(Int, Int)] = List((3,4), (1,2))

But:

scala> Set((1, 2)) ++: Seq((3, 4))
res0: Seq[(Int, Int)] = List((1,2), (3,4))

scala> Seq((3, 4)) ++: Set((1, 2))
res1: scala.collection.immutable.Set[(Int, Int)] = Set((3,4), (1,2))

> Besides, since there are methods like `+:` in Seq, people might start
> requesting that we move `+:` to Traversable too.

Well, they can't have it, because + cannot go on Seq. But ++ and ++: do
not suffer from +'s issues.

On Wed, May 26, 2010 at 06:27:26PM +0200, Aleksandar Prokopec wrote:
> Besides, since there are methods like `+:` in Seq, people might start
> requesting that we move `+:` to Traversable too.

To address that with greater clarity: ++ is already on Traversable.
Adding ++: is surely more consistent than not doing so. There is no
reason adding ++: would give people any basis for thinking +: could be
moved there as well: there is no axis of symmetry across "methods with a
:" but there is one between "identical methods with operands flipped."

> To address that with greater clarity: ++ is already on Traversable.
> Adding ++: is surely more consistent than not doing so. There is no
> reason adding ++: would give people any basis for thinking +: could be
> moved there as well: there is no axis of symmetry across "methods with a
> :" but there is one between "identical methods with operands flipped."
>
>

Ok.
In case we decide to add `++:` to Traversable, I can do so.

Cheers,
Alex

On Wed, May 26, 2010 at 06:58:52PM +0200, Aleksandar Prokopec wrote:
> In case we decide to add `++:` to Traversable, I can do so.

It's tricky. ++ is overridden in about ten different collections so
it'd be highly desirable to reuse ++, but if the signature of ++: is the
same as that of ++ then the obvious implementation of "that ++ this" is
not possible because "that" is TraversableOnce and has no ++ method.
I'm sure it's doable but it might take some pondering.

Neato, overloading + breakOut to the rescue. (Never before used in
trunk!) So the below seems to do the right thing and should use the
overridden variations except if something is typed as TraversableOnce.
If there were a behavioral difference I would be strongly against
relying on static overloading behavior, but AFAIK it is only an
efficiency issue.

def ++:[B >: A, That](that: TraversableOnce[B])(implicit bf: CanBuildFrom[Repr, B, That]): That = {
val b = bf(repr)
if (that.isInstanceOf[IndexedSeqLike[_, _]]) b.sizeHint(this, that.size)
b ++= that
b ++= thisCollection
b.result
}
def ++:[B >: A, That](that: Traversable[B])(implicit bf: CanBuildFrom[Repr, B, That]): That =
that.++(this)(breakOut)

I agree - and views might need some reworking too - in particular the
Prepended view will probably have to be renamed or reworked.

Alex

On 26/05/10 19:05, Paul Phillips wrote:
>
> It's tricky. ++ is overridden in about ten different collections so
> it'd be highly desirable to reuse ++, but if the signature of ++: is the
> same as that of ++ then the obvious implementation of "that ++ this" is
> not possible because "that" is TraversableOnce and has no ++ method.
> I'm sure it's doable but it might take some pondering.
>
>