CLS compliance and its impact on API design

[sakno]

As of today, CLSCompliant attribute and the requirements behind it mostly are the part of history. Many libraries shipped with .NET are not CLS-compliant. Should I, as an author of 3rd party library, continue to support this concept? I don't mean just to apply the attribute at assembly level. I mean usage of signed integer types where it is not desirable. For instance, array or collection length is int. However, it is impossible to have negative value. There are lot of similar things, when ctor or method accepts long/int then just checks whether it's not negative (otherwise, throw ArgumentOutOfRangeException). Is it reasonable to replace those with unsigned counterparts? For instance, I have Write-Ahead Log and each record is indexed using long. I'm loosing 1 bit of information (I can store [0..(2^31-1)] range instead of [0..2^32-1]) to store large index numbers. In the same time, it is not possible to have negative indexes.

[tannergooding]

Is it reasonable to replace those with unsigned counterparts?

It is still beneficial to utilize signed types in normal managed APIs. This is primarily because everything else in the ecosystem takes signed types and it avoids the messiness of needing to cast or handle overflow.

I'm loosing 1 bit of information (I can store [0..(2^31-1)] range instead of [0..2^32-1])

Many scenarios don't actually need this extra bit and you may end up "losing" it anyways when interacting with most other existing APIs, like say Span<T>, where it only takes a signed type anyways.

As of today, CLSCompliant attribute and the requirements behind it mostly are the part of history

CLSCompliant is missing a lot of concepts and there are many newer language/runtime features that don't properly track the existing definition of compliance (that is the language won't warn that its missing the attribute) -or- that have never had their relationship with the general concept of compliance considered (e.g. Span<T>, ref struct, DIMs, static virtual in interfaces, generic math, etc).

Due to that, the actual proper tracking of the attribute isn't as important as it once was. However, the general concepts behind the attribute do still exist and apply in many cases. They still make a difference in how easy your APIs are to use from other existing .NET code or how easily your code can call other existing .NET code. They still make a difference as to whether the APIs can be consumed downlevel, as to whether they can be consumed from other languages (VB, F#, IronPython, etc). They still make a difference in how the BCL designs its APIs and whether we consider providing alternative overloads or ways to access the same or similar functionality.

In general, you should consider the "Framework Design Guidelines". This has the general rules outlined publicly: https://learn.microsoft.com/en-us/dotnet/standard/design-guidelines/. But for which there is also a newer version of the annotated book was published a couple years back: https://www.amazon.com/Framework-Design-Guidelines-Conventions-Addison-Wesley/dp/0135896460. The book expands more on the rules, the reasonings why, and may have some updated guidance taking into account newer language features.