Maybe we can deprecate PF.apply in 2.12.4 and remove it in 2.13? Then we could bring it back (with a PF parameter type) in 2.14.

I didn't know you could deprecate something in the middle of a release cycle.

I think usually not, but this might be exotic and confusing enough to make an exception.

Why can't you remove it and replace it in one go?

@Jasper-M I think that it's that if you repeal remove and replace it on one go, then code like

val x = PartialFunction[String, Boolean] { case "bippoid" => true }

will compile before and after, but have silently different semantics, which is potentially a pitfall for migration. Granted, the 2.12.x behaviour is almost certainly not wanted, but still...

True, but is that still the case when you deprecate something in the beginning a new major release (2.13.0 for instance)? Cause then it's been deprecated for a whole release cycle. Then you can't say you haven't been warned.

Let's deprecate apply in 2.12.5 and drop it in 2.13. Maybe we shouldn't be using apply at all here, because it's just confusing in general when dealing in functions? Adding a type ascription as suggested by the deprecation message is cleaner anyway, IMO.

👍 to that plan — as I understand it, the recommended upgrade path for users to move to a new major Scala release has always been to upgrade to the newest point release from the last version first, fix all deprecation warnings, then bump the major version

Sounds good. I'll clean this up somewhere this week.

If we deprecate apply in 2.12.5, we can't add fromFunction at the same time. Should the deprecation message suggest using val pf: PartialFunction[A,B] = { case x => f(x) } instead of PartialFunction(f)? And then add fromFunction in a separate pull request to 2.13.x?

A hypothetical workaround might be to implement fromFunction in 2.12.5 with a macro...

I don’t see why we can’t add fromFunction in 2.13 immediately. The deprecation message can’t refer to it in 2.12, true.

Well yes, then I would need separate pull requests for both?

Then again, do we need it at all? I don’t know, having a hard time imagining the use case

I'm not sure, but it's there so I guess people might be using it. The best use case I can imagine is circumventing some badly designed API.

Fine by me. I don't use it anyway 😅

FWIW I'm pretty sure I've had times where I had a function instance and something expected a PartialFunction, and .apply came in handy.

Definitely, but this is about the apply method in the companion -- sounds like you're talking about the one in the class?

No, on the companion. (I suppose the instance method would be the opposite case but anyway that's definitely not what I'm talking about!)

I'm not sure we reached a clear conclusion on whether there ought to be a followup PR that adds PartialFunction.fromFunction in 2.13. "I'm pretty sure I've had times" suggests that perhaps we should, but I think we probably need clearer evidence than that in order to justify it.

related but separate question — do we want to actually remove PartialFunction.apply in 2.13, or just leave it deprecated one version longer? we do like to get rid of deprecated stuff, but to actually get rid of it in 2.13 when the deprecation hasn't even happened yet (2.12.5 isn't out yet) seems like an especially fast timetable for removal to me, I don't think we need to get rid of stuff quite that fast unless it's standing in the way of something else.

Perhaps add fromFunction and adjust the deprecation message in 2.13 then?

If it helps, I am absolutely sure I have needed PartialFunction.fromFunction quite a bit. I am not sure if it's an edge case but I work with scalafix a fair bit which has an api that is largely based around collecting over trees, and it isn't that uncommon to find myself down a path where at a particular point I have a partial function and it wants a partial function.

I just want to chime in with my 2¢ that I don't like the proposal (perhaps no longer on the table) to replace this with a new apply in 2.13.0. It seems unnecessarily dangerous to deprecate something in 2.12.5 and then replace it with a method that will accept the old source code but silently misbehave in 2.13.0.

If the plan is ultimately to replace the apply with a source-incompatible version, my (unsolicited) opinion would favor removing it in 2.13 rather than leaving it with a deprecation. Yes, there would have been a deprecation for a full version cycle, but the consequences of the behavior change if somebody misses the deprecation warning are potentially catastrophic. (It is clearly a good idea to enable them, but scalac doesn't even show the actual deprecation warnings by default.)

The need to cross-compile libraries in Scala exacerbates the issue as people have code that's simultaneously compiled against several versions. A compilation failure makes clear the danger here.

I'm also +1 for adding a PartialFunction.fromFunction (or Function.toPartial). When basic stuff like this is left out of the standard library, it just winds up accumulating little helpers in a million projects. I think there are enough use cases that it belongs

Thanks, @sarahgerweck, and your opinion is very much solicited, and appreciated. I share the concern of silently changing behavior. We can't assume all deprecation warnings will be seen.

So, to summarize proposed next steps: add fromFunction in 2.13 and drop apply. Once available, we can update the deprecation message in 2.12.x to say this will be available as fromFunction in 2.13. It should be easy to cross-compile using fromFunction in both versions, supplying it as an extension method on 2.12. I do think the distance between 2.12 and 2.14 is great enough that we could consider adding apply again as a shorter version for fromFunction, although I'm not that worried about terseness, and more about clarity. apply is too overloaded in this context.

@nafg, sorry for misunderstanding your earlier comment. Do you find this an acceptable compromise?

PS: If we are too worried about dropping apply (I'm not), we could instead add an implicit argument of type DoNotUse, with an implicitNotFound annotation that says to use fromFunction :-) This makes it very unlikely people will call it accidentally, and provides another helpful migration message.

So, to summarize proposed next steps: add fromFunction in 2.13 and drop apply. Once available, we can update the deprecation message in 2.12.x to say this will be available as fromFunction in 2.13.

Sounds good to me.

It should be easy to cross-compile using fromFunction in both versions, supplying it as an extension method on 2.12.

You mean the person who is cross-compiling can easily add that extension himself?

I do think the distance between 2.12 and 2.14 is great enough that we could consider adding apply again as a shorter version for fromFunction, although I'm not that worried about terseness, and more about clarity. apply is too overloaded in this context.

The short version of fromFunction is what was deprecated here 😜 But I agree it's probably better not to add a different apply after removing this one.

Nit, but it seems to me PartialFunction.from is enough, PartialFunction.fromFunction is redundant.