Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add safe counterpart methods for collections #127

Open
danicheg opened this issue Aug 7, 2022 · 3 comments
Open

Add safe counterpart methods for collections #127

danicheg opened this issue Aug 7, 2022 · 3 comments

Comments

@danicheg
Copy link

danicheg commented Aug 7, 2022

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
Copy link
Author

danicheg commented Aug 7, 2022

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
Copy link

I see there is a ticket over there to migrate 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
Copy link

[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.

@SethTisue SethTisue transferred this issue from scala/bug Aug 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants