search

scala / bug

Scala 2 bug reports only. Please, no questions — proper bug reports only.
https://scala-lang.org
231 stars 21 forks source link

Make Map#{mapValues, filterKeys} strict #11245

Open shawjef3 opened 5 years ago

shawjef3 commented 5 years ago

This is a followup for #10919. Is to be done for version 2.13.1 or 2.14?

joshlemer commented 5 years ago

This is to be done in 2.14 at the earliest, because to change them in 2.13.1 would mean to break binary compatibility.

shawjef3 commented 5 years ago

Ah, of course. Although it wouldn't break binary compatibility if mapValues and filterKeys were to return a Map rather than a MapView, yes? The type wouldn't reflect the laziness, but we could change it sooner. The @deprecated warning would notify the user that it's lazy.

Jasper-M commented 5 years ago

It would break semantic compatibility, if that's a thing.

shawjef3 commented 5 years ago

I've been burned by mapValues being lazy, and so I consider it a performance bug. I'm happy there's a plan to make it strict for 2.14. 2.13 would be better but I understand the motivation to be careful. Since I consider it a bug I don't feel the need to be careful.

For why I feel so strongly about mapValues: https://github.com/lihaoyi/fastparse/pull/70

Jasper-M commented 5 years ago

Agreed that it's great that this will change, but by now a lot of people are aware that mapValues is lazy and use it accordingly.

NicolaeNMV commented 3 years ago

.mapValues got deprecated without a good alternative and no plan when exactly this will be addressed ?

In the previous thread @szeiger wrote:

Maybe we can make the versions on Map strict in 2.14 after a deprecation cycle without removing them first?

Is this still on track ?

Just making sure that this issue is not abandoned. Because it looks like it is abandoned. It's really painful that mapValues now needs .view.mapValues(f).toMap every time. People switched to .transform that is a lot less readable. Thanks.

SethTisue commented 3 years ago

@NicolaeNMV the situation hasn't changed: as per https://www.scala-lang.org/2019/12/18/road-to-scala-3.html and https://github.com/scala/scala-dev/issues/661 and Josh's remark above, we aren't free to add new methods to the Scala standard library in the 2.13.x and 3.0.x series (or to drastically alter the semantics of existing methods). Meanwhile, this ticket remains open and is milestoned appropriately. (I've renamed the old "2.14.0-M1" milestone to "3.x".)