NotificationsYou must be signed in to change notification settings
Fork1.1k
Star6.2k

Add string singleton comparison operators to scala.compiletime.ops.string.#24748

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Jump to bottom

Open

wtetzner wants to merge1 commit intoscala:main

base:main

Choose a base branch

fromwtetzner:string-singleton-comparisons

Open

Add string singleton comparison operators to scala.compiletime.ops.string.#24748

wtetzner wants to merge1 commit intoscala:mainfromwtetzner:string-singleton-comparisons

+111 −1

Conversation

Copy link

wtetzner commentedDec 14, 2025

The numeric singleton types already have comparison operators, but for some reason this was still missing for singleton String types.

This enables a lot of potential valuable type-level computations, but one in particular is the ability to sort a named tuple, which means that if you're commonly adding/removing entries from a named tuple, this provides a way to normalize them, so two named tuples that were constructed in a different order can still be treated as equivalent types.

Test results:https://gist.github.com/wtetzner/6f38842c5d06a5d70ba5eea2cf7ce298

wtetzner requested a review froma team as acode owner

December 14, 2025 02:59

Add string singleton comparison operators to scala.compiletime.ops.st…

f5d3a15

…ring.The numeric singleton types already have comparison operators, but forsome reason this was still missing for singleton String types.This enables a lot of potential valuable type-level computations, butone in particular is the ability to sort a named tuple, which means thatif you're commonly adding/removing entries from a named tuple, thisprovides a way to normalize them, so two named tuples that wereconstructed in a different order can still be treated as equivalenttypes.

wtetzner force-pushed thestring-singleton-comparisons branch from881ae82 tof5d3a15Compare

December 14, 2025 05:28

Copy link

Member

bishabosha commentedDec 15, 2025•
edited
Loading

i wonder if its generally useful to also have tuple sorting itself as a type operation - perhaps it can have a binary op "comparator" argument as well (so< et all can still be added) - of course you do need to remember the order of the pairs of key, value so i guess you pair, sort and then unzip (which it looks like your demo does)

Copy link

ritschwumm commentedDec 15, 2025

not sure this makes sense: there is no single lexicographic order for strings, thisalways depends on the locale.

Copy link

Author

wtetzner commentedDec 15, 2025•
edited
Loading

not sure this makes sense: there is no single lexicographic order for strings, thisalways depends on the locale.

Are you sure? I don't think Java's default String comparison depends on locale, and I believe that's what Scala's comparison operators use. It's case folding that needs locale, and we're not doing that here.

I think you need to useCollator for locale-dependent sorting.