Why is String.Length signed?

Question

Possible Duplicate:
Why does .Net Framework not use unsigned data types?

In The C# Programming Language (Covering C# 4.0) (4th Edition), 1.3 Types and Variables, Page 9.

Hooray for byte being an unsigned type! The fact that in Java a byte is signed (and with no unsigned equivalent) makes a lot of bit-twiddling pointlessly error-prone. It’s quite possible that we should all be using uint a lot more than we do, mind you: I’m sure many developers reach for int by default when they want an integer type. The framework designers also fall into this category, of course: Why should String.Length be signed?

When I decompile String.Length;

/// <summary>
    /// Gets the number of characters in the current <see cref="T:System.String"/> object.
    /// </summary>
    /// 
    /// <returns>
    /// The number of characters in the current string.
    /// </returns>
    /// <filterpriority>1</filterpriority>
    [__DynamicallyInvokable]
    public int Length { [SecuritySafeCritical, __DynamicallyInvokable, MethodImpl(MethodImplOptions.InternalCall)] get; }

Also in MSDN;

The Length property returns the number of Char objects in this instance, not the number of Unicode characters. The reason is that a Unicode character might be represented by more than one Char.

It returns the number of character objects in the current string. Why does String.Length return Int32 when there already is a type called UInt32? What is the point of the signed-unsigned byte and String.Length?

score 11 · Answer 1 · edited May 23 '17 at 10:27

11

Because all .NET core objects are CLS compliant. And CLS has no unsigned data types.

Check

Why are unsigned int's not CLS compliant?

for the details.

edited May 23 '17 at 10:27

Community

1
1

answered Jan 03 '13 at 21:02

TomTom

61,059
10
88
148

2

Well, not quite. `byte` is CLS compliant, and it's unsigned. – Robert Harvey Jan 03 '13 at 21:04
Yes. This is about the language independent part, and somehow not all languages can deal with them. That is funny, though, as the unified type system otoh - well, it is complex. Big turnaround, it is a pain, but that is how it is ;) – TomTom Jan 03 '13 at 21:04

Robert Harvey · Accepted Answer · 2013-01-03T21:40:19.820

10

Int32 is widely considered to be the "general-purpose" integer in the .NET framework. If you need a general number that is not fractional, Int32 is what you reach for first. You would only use one of the unsigned types if you had a specific reason to do so.

Using int for all Count properties creates a consistent API, and allows for the possibility of using -1 as a flag value (which some APIs in the framework do).

From http://blogs.msdn.com/b/brada/archive/2003/09/02/50285.aspx:

The general feeling among many of us is that the vast majority of programming is done with signed types. Whenever you switch to unsigned types you force a mental model switch (and an ugly cast). In the worst cast you build up a whole parallel world of APIs that take unsigned types.

edited Jan 03 '13 at 21:40

answered Jan 03 '13 at 21:01

Robert Harvey

178,213
47
333
501

Well, that sadly is not the correct answer ;) See mine ;) – TomTom Jan 03 '13 at 21:03
5

Thanks for the downvote, but your answer doesn't really invalidate mine. – Robert Harvey Jan 03 '13 at 21:04
+1 for karma :-) I think this is a reasonable justification for use of `Int32`. Having said that, TomTom's answer is probably what actually happened in practice, so I voted for both of you. – Christian Hayter Jan 03 '13 at 21:09
2

Unless either of you have some reference to an actual Microsoft employee stating the reason that they choose to use this, we can only ever theorize what possible reasons might have been. – Servy Jan 03 '13 at 21:14
Even more important than the fact that -1 can be used as a flag value is that there's no question about how subtraction of `Int32` values should work. Given variables `x` and `y` of type `UInt32`, there are three plausible meanings a language might assign to `x-y`: yield a `UInt32` holding the result mod 4294967296, yield an `Int64` holding the arithmetically-correct result, or yield a `UInt32` which holds the arithmetic result when positive and throw an exception otherwise; the only interpretation which would avoid run-time surprises would require promotion to `Int64`, but that would make... – supercat May 13 '15 at 17:51
...`UInt32` types rather burdensome to work with. – supercat May 13 '15 at 17:51

Why is String.Length signed?

2 Answers2