Remove extracting(Function) from Iterable assertions#3854
Open
PatrickWalter214 wants to merge 3 commits intoassertj:mainfrom
Open
Remove extracting(Function) from Iterable assertions#3854PatrickWalter214 wants to merge 3 commits intoassertj:mainfrom
extracting(Function) from Iterable assertions#3854PatrickWalter214 wants to merge 3 commits intoassertj:mainfrom
Conversation
scordio
added
the
event: Hack.Commit.Push
In Kotlin the call to extracting with a lambda for an iterable assert is ambiguous. This is due to the extracting method existing for ThrowingExtractor and Function, which have the same effective signature, as checked exceptions do not exist in Kotlin. We opt to continue using the extracting method for ThrowingExtractor, since it is the more flexible functional interface, as it supports that the lambda provided can throw an exception.
PatrickWalter214
force-pushed
the
gh-1499-extracting-ambiguous-signature-kotlin
branch
from
53df5dd to
fe69a89
Compare
scordio
changed the title
extracting(Function) from Iterable assertions
scordio
force-pushed
the
main
branch
2 times, most recently
from
b2b071f to
2dab02c
Compare
…ing-ambiguous-signature-kotlin
scordio
reviewed
Nov 20, 2025
Member
scordio
left a comment
scordio
left a comment
There was a problem hiding this comment.
Many thanks @PatrickWalter214 for your efforts, and sorry for such a big delay!
There are a couple of things I'd like to do differently, but I'm taking care of them directly.
assertj-core/src/main/java/org/assertj/core/extractor/ThrowingExtractors.java
Outdated
Show resolved
Hide resolved
...-core-kotlin/src/test/kotlin/org/assertj/tests/core/kotlin/api/Assertions_assertThat_Test.kt
Outdated
Show resolved
Hide resolved
scordio
reviewed
Nov 21, 2025
| * @return a new assertion object whose object under test is the list of values extracted | ||
| */ | ||
| @CheckReturnValue | ||
| public <V> AbstractListAssert<?, List<? extends V>, V, ObjectAssert<V>> extracting(Function<? super ELEMENT, V> extractor) { |
Member
There was a problem hiding this comment.
As discussed today with @filiphr, removing the overload accepting Function will break compatibility with all the existing Function implementations that cannot be easily transformed into a ThrowingExtractor, such as those coming from third parties.
A better strategy is likely to keep extracting(Function) and add to ThrowingExtractor factory methods that ease wrapping code that throws exceptions, similar to how the Spring Framework does.
I'll analyze the topic again and come up with a better proposal.
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
In Kotlin, the call to extracting with a lambda for an iterable assert is ambiguous. This is due to the
extractingmethod existing forThrowingExtractorandFunction, which have the same effective signature, as checked exceptions do not exist in Kotlin. We opt to continue using the extracting method forThrowingExtractor, since it is the more flexible functional interface, as it supports that the lambda provided can throw an exception.Check List:
extracting()when using Kotlin #1499