mdedetrich commented on PR #1980:
URL: https://github.com/apache/pekko/pull/1980#issuecomment-3139474886
> ... meaning for example now we cannot "just" add a second parameter to the
`InternalImplementation` apply method, as artifacts compiled against the
previous method would still have inlined references to the old apply method.
So indeed this is a case of what I said earlier, specifically
> Or are you stating that since the inlining is an actual literal inline we
should mark the callers of the Scala 3 inline methods in some fashion because
its possible that if we happen to change the implementation of the Scala 3
inline methods that it may not be reflected depending on what artifact gets
resolved in the satellite project? If so I can see the concern here, however in
the specific case of this PR those scala 3 inline method implementations are
pretty much guaranteed to never change. They have never changed in the pekko
1.0.x series given that they just happen to delegate to methods from Scala SDK
(or Scala SDK equivalent).
> Of course the inlined methods in this PR are completely fine, I just would
sleep better if we have this documented to help avoid falling foul of this in
the future.
Agreed, with this PR its entirely non issue since the implementation of the
Scala 3 inline functions is never going to change for the lifecycle of 2.0.x
but indeed newer contributors can run afoul of this if they don't understand
the context.
Maybe its best that we add a statement in `CONTRIBUTING.md` stating that any
functions that use inline (whether its Scala 2 or Scala 3) must have its
implementations remain static if they use `@InternalStableApi`? I can make a
separate PR for this.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscr...@pekko.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscr...@pekko.apache.org
For additional commands, e-mail: notifications-h...@pekko.apache.org
