[API Proposal]: System.Globalization.CompareOptions.UseNLS

[clement911]

Background and motivation

Using NLS instead of ICU can currently only be configured with a global flag.
See https://learn.microsoft.com/en-us/dotnet/core/extensions/globalization-icu#use-nls-instead-of-icu
This new API would allow the use of NLS on a per API call basis.

API Proposal

Add a new flag System.Globalization.CompareOptions.UseNLS

API Usage

CompareInfo.GetCompareInfo("en-US").Compare(str1, str2, CompareOptions.UseNLS)

Alternative Designs

I can't think of any

Risks

I can't think of any

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-globalization
See info in area-owners.md if you want to be subscribed.

[teo-tsirpanis]

I don't think we should be encouraging users to rely on NLS in the long term, especially for new apps. NLS is Windows-specific while ICU is standard and cross-platform.

[clement911]

Not encourage but it is sometimes needed to use NLS.
See #99507

[teo-tsirpanis]

SqlString should call NLS APIs by itself. I don't see a reason to expose a general-purpose API for NLS comparisons.

[clement911]

SqlString delegates to System.Globalization.CompareOptions for its comparison logic.

See:

runtime/src/libraries/System.Data.Common/src/System/Data/SQLTypes/SQLString.cs

Lines 684 to 705 in b181ed5

	public static CompareOptions CompareOptionsFromSqlCompareOptions(SqlCompareOptions compareOptions)
	{
	CompareOptions options = CompareOptions.None;
	ValidateSqlCompareOptions(compareOptions);
	if ((compareOptions & (SqlCompareOptions.BinarySort | SqlCompareOptions.BinarySort2)) != 0)
	throw ADP.ArgumentOutOfRange(nameof(compareOptions));
	else
	{
	if ((compareOptions & SqlCompareOptions.IgnoreCase) != 0)
	options |= CompareOptions.IgnoreCase;
	if ((compareOptions & SqlCompareOptions.IgnoreNonSpace) != 0)
	options |= CompareOptions.IgnoreNonSpace;
	if ((compareOptions & SqlCompareOptions.IgnoreKanaType) != 0)
	options |= CompareOptions.IgnoreKanaType;
	if ((compareOptions & SqlCompareOptions.IgnoreWidth) != 0)
	options |= CompareOptions.IgnoreWidth;
	}
	return options;
	}

runtime/src/libraries/System.Data.Common/src/System/Data/SQLTypes/SQLString.cs

Lines 401 to 403 in b181ed5

	CompareOptions options = CompareOptionsFromSqlCompareOptions(x.m_flag);
	iCmpResult = x.m_cmpInfo!.Compare(x.m_value, 0, cwchX, y.m_value, 0, cwchY, options);

I guess it could be a new internal API, although I don't see the harm of exposing this flag since it would be off by default.
Also, there might be other public packages that might want to use it.

[MichalPetryka]

SqlString should call NLS APIs by itself. I don't see a reason to expose a general-purpose API for NLS comparisons.

That probably won't happen since it'd make SqlString Windows only.

[jkotas]

Globalization tables are moving target. If SqlString assumes that the globalization tables are fixed, it sounds like a design flaw in SqlString that should be fixed in SqlString.

[clement911]

Any updates on this?
We continue to find more characters that are not handled properly by SqlString (see #99507 (comment))

Can we loop in someone that owns SqlString, or knows more about it?

[jkotas]

The main issue is tracked by #99507