Deprecate the helpers in scala.deriving. #10436
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
* `ArrayProduct`
* `EmptyProduct`
* `productElement`
These helpers are not mandated by the spec, nor used by the
compiler. They were used in a few tests for typeclass derivation,
but it does not seem that they are fundamental. We now use
replacements in the relevant tests.
`EmptyProduct` can be replaced by `EmptyTuple`.
`ArrayProduct` seems to be used by "unpickling" kinds of
derivations (an impression confirmed by the community build). This
is too specific a use case to be defined generally in
`scala.deriving`. Moreover, it is not clear why Arrays receive
special treatment, but not other kinds of sequences or even
immutable arrays. `ArrayProduct` can be replaced by a custom
`new Product {...}` wrapper, which in the case of our tests ends up
being simpler than the "feature-rich" `ArrayProduct`.
`productElement` seems to be more generally useful, but at the same
time is very unsafe, and is not hard to re-implement. Removing it
forces the call sites to perform the `asInstanceOf`s themselves,
which is not a bad thing as it allows to better reason about the
code. In particular, our tests benefitted from pushing the cast to
`Product` ahead in the call chain, at a place where it is
relatively easier to convince oneself that the value is indeed a
`Product`.
sjrd
force-pushed
the
deprecate-scala-deriving-helpers
branch
from
55988b3 to
0f24d27
Compare
|
Approved during the meeting. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
ArrayProductEmptyProductproductElementThese helpers are not mandated by the spec, nor used by the
compiler. They were used in a few tests for typeclass derivation,
but it does not seem that they are fundamental. We now use
replacements in the relevant tests.
EmptyProductcan be replaced byEmptyTuple.ArrayProductseems to be used by "unpickling" kinds ofderivations (an impression confirmed by the community build). This
is too specific a use case to be defined generally in
scala.deriving. Moreover, it is not clear why Arrays receivespecial treatment, but not other kinds of sequences or even
immutable arrays.
ArrayProductcan be replaced by a customnew Product {...}wrapper, which in the case of our tests ends upbeing simpler than the "feature-rich"
ArrayProduct.productElementseems to be more generally useful, but at the sametime is very unsafe, and is not hard to re-implement. Removing it
forces the call sites to perform the
asInstanceOfs themselves,which is not a bad thing as it allows to better reason about the
code. In particular, our tests benefitted from pushing the cast to
Productahead in the call chain, at a place where it isrelatively easier to convince oneself that the value is indeed a
Product.Since it looks like we're going to release an M2, it makes sense to deprecate in M2, and later remove in RC1. Compared to #10405, I have done deeper changes in the tests, that illustrate that the replacements are actually better, IMO, than using the helpers anyway. Especially, the decoupling of the places where the two casts of the former
productElementseems really easier to reason about, IMO.