scala / scala-library-next

backwards-binary-compatible Scala standard library additions
Apache License 2.0
67 stars 17 forks source link

Add safe counterpart methods for collections #127

Open danicheg opened 1 year ago

danicheg commented 1 year ago

Hey there. Have a nice day by contributing to Scala! Perhaps, I'll ask kinda annoying a heavily discussed previously question, but do you mind adding safe counterpart methods for collections? Say, scala.collection.Iterable has head method and its safe counterpart headOption. So it's seemed natural to add safe counterparts for methods init, tail, etc. There is demand in the FP community for such methods, like this recent PR to mouse library. Doubtless, Scala is great with its mechanisms of creating extension methods. But speaking from the allocations perspective, it'd be much better to have those methods in the collection library straightforwardly. So, what do you think about adding those methods to the 2.13 (or more likely to 2.14 if we'll have it in a wild) collections library? If this 'issue' is a duplication, feel free to close it.

danicheg commented 1 year ago

I've got some intuitions from @armanbilge (thanks Arman) that:

  1. We can't add new methods to the standard library in 2.13.x series, because of binary compatibility constraints.
  2. Even there won't be Scala 2.14.
  3. We have https://github.com/scala/scala-library-next.

But at this point, scala-library-next seems like a placeholder for additions of extension methods, not straightforward methods to classes. So, we can't add new public methods straightforwardly to Scala 2 collections library, nor to Scala 3 one, and extension methods are the only available option?

som-snytt commented 1 year ago

I see there is a ticket over there to migrate issues. https://github.com/scala/scala-library-next/issues/12 But I don't know if an issue would receive attention there.

I think scala-library-next is about API-breaking changes and not implementations per se. There is not a mechanism for deciding what is accepted or in what form or when.

Safe alternatives are requested, such as for enum.valueOf. I don't think there is a ticket for collections.

list.tail is list.drop(1), which is safe in the sense of Nil.drop(1).

There are also indexing ops which sometimes throw and sometimes don't. "abc".slice(1,100) versus Java's substring that throws.

som-snytt commented 1 year ago

[the building] is redefining the city’s skyline and providing individuals who wish to live downtown with greater optionality.

Housing for the FP community. It's a very safe neighborhood, of course.