Ondra Karmazín

[`kotest-assertions-arrow`](https://kotest.io/docs/assertions/arrow.html) does not mention the fact that its versioning is independent from the main Kotest libraries. One has to go to the [Maven repo](https://repo.maven.apache.org/maven2/io/kotest/extensions/kotest-assertions-arrow/) to find the current version.

Add information about Bluetooth Classic to the README or change terminology to "BLE"

2

The README is confusing. It insists on using the word "Bluetooth" (which means Bluetooth Classic), but then all examples are given in terms of BLE. They are not interchangeable. Does...

Kotlin: Handle language-level nullability and default values as orthogonal to each other

7

The current behavior implemented in response to #716 is incorrect. Whenever a property is `not nullable`, it gets marked as `required` even if it has a default value, which is...

- Adds shouldBeSortedDescending for primitive arrays - Generalizes the matchers from List to Iterable BooleanArray omitted - it is not very natural to check if a collection of booleans is...

[Design] Should collection assertions throw if assertion "correctly" passes for any value due to empty container?

3

This ticket is a result of a discussion with @LeoColman - https://github.com/kotest/kotest/pull/4378#discussion_r1779820867 TODO: I will add the description and the argued positions later. This is just so I don't forget...

Collection matchers should work on primitive arrays

2

A picture is worth a 1000 words they say. There should be no problem implementing it the same way the current matchers on Array work - through `.asList()` - [...

Surfacing this for the work I do on modernizing collection assertions. While Iterable implementations are generally expected to return a fresh Iterator on each call to `.iterator()`, allowing for repeated...

TODO: After https://github.com/kotest/kotest/pull/4369 Also, use the shared impl going forward. Right now it is duplicated in order to make PRs independent. _Originally posted by @LeoColman in https://github.com/kotest/kotest/pull/4378#discussion_r1779820481_

Sequence monotonicity assertions are misplaced in the `collection` package, they should be moved to the correct `sequence` package. This is the kind of change where deprecation annotations containing "replaceWith" will...

These assertions are just inversions, aren't they? Therefore, it shouldn't be necessary to keep both `Container.shouldBeUnique` and `Container.shouldNotContainDuplicates`. I propose removing the `shouldContainDuplicates` variety since it is more verbose.