Implicit enrichment of `scala.util.Either` to support monadic bias

[swaldman]

I'm sorry this has taken so long to generate. I hope that it isn't terrible.

It's a long-promised follow-up to closed Scala pull request 4547.

[dickwall]

@swaldman please coordinate with the expert group on https://github.com/scala/slip/issues/5 and also make them aware of this proposal. We believe these efforts should be rolled in together.

[soc]

Shall we close this as "fixed"?

[swaldman]

I think closed, not fixed would be a more accurate description.

The solution adopted fails to address the problem that motivated the proposal, which was to render Either fully compatible with for comprehensions, including guards, pattern-matching, and assignment.

For the record, I don't think this evolution was fairly or reasonably handled. Whether or not, as a technical matter, the compromise adopted is the best possible in a complicated world I can't say. Maybe, maybe not. But the process was not so great. After I was asked to produce a SLIP, following a PR, and then full documentation of the PR, the SLIP was ignored until a different, and in my perhaps mistaken view inferior, PR was summarily accepted. I love Scala, and love writing libraries for Scala, but would be extremely hesitant to devote further effort to Scala standard library or language-related projects.

[lrytz]

Thank you @swaldman for the honest feedback. We are aware that there are a lot of struggles with the sip/slip process, in the past and in the present, and this is a "good" example. A new effort to put the process on track has been started recently, your feedback is a very valuable input. cc @jvican.

[jvican]

Sad to hear that @swaldman; I completely understand your position. What you have described is, however, the crude reality. I believe that we need to accept the failure of our mechanisms to collect input from the community, given the reaction of most of the previous SIP/SLIP authors I have talked to and several complaints we have received.

Addressing this problem has been a main concern for the Scala Center, which has assigned me to rework both projects. You can see some of the results in the new specification of the SIP process. The SLIP process is, conversely, being reworked right now and we're expecting to have the first SLIP meeting in August, with a new committee composed only of community members (no compilers maintainers, only people that have been active in the community and have the technical expertise and the influence to manage the new platform, that is, the modules of the standard library).

I will use your experience as a clear example of what shouldn't happen again. My main goal with the new design is to give quick feedback to authors and never ignore SLIPs, having a clear understanding of what the status of a SLIP is and when it's going to be processed. Also, having someone responsible of managing the whole process helps, people usually forget their commitments. It's natural, though, since most of them have a busy work and personal life.

Of course, I'm not saying this is going to be definite process because who knows? Being honest and realistic, I could fail again in the execution of this task. But I can only have hopes and strive for a successful SLIP process, and show the community that we have good in-place mechanisms to process their feedback and improve the language for the good of all. Despite my previous realistic revelation, I'm optimistic that we'll eventually reach that point.

Thanks for your feedback on this SLIP. Thanks for reminding @lrytz, I started to write my response yesterday, but didn't have time to finish it up.

[swaldman]

@lrytz @jvican thank you very much for your responses. i appreciate it.

[soc]

@swaldman I just wanted to say thank you for your work. You might feel that your effort was in vain, but it really shaped and informed the decisions I made while working on Either. I spent quite some time thinking about your proposal and I think without it, I still wouldn't be completely sure whether we had considered all possible options.

Let me go into some detail why in the end the result looked quite different from your proposal. My main concerns where three-fold:

• The approach would have introduced an idiom which didn't exist before in this form in the standard library.
• I felt that it required quite some setup and boilerplate (which is not your fault, but Scala's) which would have made it more like scala.Enumeration in terms of usage (in the sense of "here is a tiny DSL you need to know" instead of "here are some methods on a type and it's obvious how they work").
• I was unsure how it would have interacted if we ever got a Monoid type and wanted to add filter. Even in the best case we would have had new deprecations and devs code to delete.

How did this impact the changes I made to Either?

• Keep the API footprint as low as possible and keep the API as vanilla Scala-standard-library style as possible. With the deprecation of the projections we will have a lot less API than we started with. I think this will make it easier to evolve Either in the future.
• Do the minimal amount of work that might make people happy. For instance I experimented with a LeftBiasedEither, but in the end decided against including it for now–with the option to add it if tons of people really miss it.
• Don't close the door on a future filter(p: B => Boolean)(implicit empty: Monoid[A]), so we have filterOrElse for doing approximately the same thing without taking up the filter name.

I can understand why you are frustrated, but in my book you contributed a ton of important, substantial work that shaped the outcome and I think Either is in a better shape now, and prepared for future improvements.

Regarding you disappointment of the process: To be honest, I have become less and less enamored with the SIP/SLIP process over time. It feels like there are basically three different categories of proposals and in my opinion each of them could have been served better with established processes:

1. Things like trait constructors, async etc. which could have been discussed on internals, and where the big writeup of the details would have happened anyway, with or without the SIP process.
2. Things that should have been a simple PR, like this one.
3. Things like trailing commas or JSON that should have either been a mail to internals, answered by "no", or a PR, closed the minute it was opened.