[C++ API] Should StringSearch constructor accept RuleBasedCollator as const?

[Alexander Turenko]

Dear ICU Team,

It seems that the StringSearch class effectively uses the collator as const and
one collator may be used across several threads if the collator is not modified
by any of them.

However, from the API point of view ([1]) the RuleBasedCollator is accepted as
non-const. Then, several lines below usearch_openFromCollator(), which accepts
const UCollator, is called, and it is the only usage of the RuleBasedCollator
argument.

It seems for me that the RuleBasedCollator argument can be declared as const
here. Am I correct?

Note: I had an attempt to file it as an issue in Jira, but the Create red
button doesn't work for me -- just do nothing (I'm logged in). I would like
this to be tracked, however, can't file an issue by myself.

[1]: https://github.com/unicode-org/icu/blob/2c2e8adbc142a76a72cac408194e8d20701603ac/icu4c/source/i18n/stsearch.cpp#L54

WBR, Alexander Turenko

[Steven Loomis]

I’ll write you separately about the Jira question.  But Collators cannot be shared across threads, see https://unicode-org.github.io/icu/userguide/collation/architecture.html#collator 

Steven

--

Steven R. Loomis

Code Hive Tx, LLC

https://codehivetx.us

--
You received this message because you are subscribed to the Google Groups "icu-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to icu-support...@unicode.org.
To view this discussion visit https://groups.google.com/a/unicode.org/d/msgid/icu-support/0d2c3c47-fea6-41ca-9025-3ed57c7435ecn%40unicode.org.

[Markus Scherer]

On Mon, Feb 16, 2026 at 7:15 AM Steven Loomis <srlo...@unicode.org> wrote:

Collators cannot be shared across threads, see https://unicode-org.github.io/icu/userguide/collation/architecture.html#collator 

This is outdated. We have worked years ago to make calling const methods thread-safe across ICU.

I don't know why the collator argument is non-const. Maybe the StringSearch code modifies its settings/attributes?

I see that there is a getCollator() function that returns the non-const Collator pointer, and the docs say that the caller can modify the collator.

So we couldn't just change the API by adding "const". If we wanted to offer APIs with non-const Collator arguments, then we would need to add new functions or overloads, and document that, if given a const Collator, the old getCollator() will return a nullptr.

In the meantime, it looks like the clean way to use this is to clone a prototypical Collator object for each thread.

You could look into the ICU code further and make sure that really nothing modifies the collator, other than a possible nefarious caller of getCollator().

And if so, let us know -- and you could const_cast a shared Collator...

Best regards,

markus