Robin Leroy

> IMO the best style guideline re CTAD is "simply never use it." That may be your strongly-held opinion, but not necessarily ICU-TC’s—nor for that matter that of all of...

There is much more to it than using draft data. We also expose properties that should never be part of APIs, things that are not properties, etc., and we use...

Here’s the current traffic from one specific (slightly odd) user agent: 

Summarizing a discussion with @sffc in Zürich: It would likely be useful to publish, somewhere on unicode.org, a limited ICU4X-based properties inspection and UnicodeSet query tool based on current published...

> It's a bit hard to specify in the grammar. Generally that is the thrust of the recommendations of UTS55, reflecting the consensus arising from a year and a half...

Non-null pointers have been addressed by #241.

Markus, > I believe that this changes from compile-time u_strlen() to runtime u_strlen(). I don't think so. operator""sv is constexpr, but not consteval (so no guarantee that it must be...

(I am assuming here that we are still going through u16string_view via the new overload; if somehow this is going through a UnicodeString constructor, that would be another can of...

> the simplest way to make sure that one avoids a u_strlen() as much as possible seems to be to consistently use a u"string view literal"sv where the API accepts...

@markusicu: > (My recent new overloads broke the use case of a { pointer, length } initializer list, as you saw.) Is that still broken after the switch to templatized...