Why we don’t have unsigned types in the CLS


style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">One of the highlights of my career
here at Microsoft was working on version 1 of the CLS – href="http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconwhatiscommonlanguagespecification.asp">Common
Language Specification.  It
started as just one meeting between a few of the compiler and framework folks to
list off the framework design features that can be used in every language and it
turned into a >2 year project involving the top folks in the division. style="mso-spacerun: yes">  It was such fun to see Anders Hejlsberg,
Paul Vick, Peter Kukol, Jim Miller and many others arguing about what makes good
framework and programming language design. 
And then, we got to take it to the 3rd party language
community where I got to see Bertrand Meyer
argue why method overloading should not be allowed in the CLS… He almost had me
convinced! "urn:schemas-microsoft-com:office:office" />


style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> 


style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">In the end, I think we came out with
a very balanced design.  It gives
framework developers a wide range of tools to use while also requiring only the
minimal number of changes to most languages targeting the
runtime.


style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> 


style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">However there is one issue that
keeps coming up:  Why did we not
allow unsigned types (UInt32 and the like) in the
CLS?


style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Well, there are really two answers
to this question.  At the first
level some languages (such as VB.NET) do not offer full support for unsigned
types.  For example you can’t have
unsigned literals in VB.NET….  But
to be fair that is not a completely satisfying answer because when we started
the CLS you could not subclass in VB.NET either, but we extended that language
to support what we knew people would want. 
We could have done the same thing with unsigned types. style="mso-spacerun: yes">  But we didn’t. style="mso-spacerun: yes">  Why not? style="mso-spacerun: yes">  Well, that gets a deeper reason. style="mso-spacerun: yes">  In fact the same reason why early betas
of the C# language did not support unsigned types (no ushort, uint and the
like). 


style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">The general feeling among many of us
is that the vast majority of programming is done with signed types. style="mso-spacerun: yes">  Whenever you switch to unsigned types
you force a mental model switch (and an ugly cast). style="mso-spacerun: yes">  In the worst cast you build up a whole
parallel world of APIs that take unsigned types. style="mso-spacerun: yes">  The value of avoiding the “< 0” check
is not worth the inclusion of generics in the CLS. style="mso-spacerun: yes"> 


style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> 


style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">As a side note the C# guys did cave
and added unsigned types to the language primarily to support interop with
unmanaged code.

Comments (3)

  1. Kevin Westhead says:

    I agree about unsigned types in so much as I only really use them to simplify interop definitions, although this should also have been a good enough reason to see their inclusion into VB.NET as well as C# at v1.0. One other useful application of unsigned types is with bit-shifting, such as in the generation of hashcodes, since you don’t have to worry about the sign-bit.

  2. Peter Ibbotson says:

    The problem with NOT having unsigned arithmetic is that CRC algorithms and various other bits and pieces get to be a real pain to write. Anything that bit twiddles is a nightmare to write. I’ve done these in VB6 using currency to get code that always worked regardless of the overflow flag but it’s a pain. (mind you I also hand decoded ethernet packets off a scope to check that my CRC calculation was correct, so perhaps I’m a special case)

  3. seeyou says:

    WhatistheCLS:CommonLanguageSpecification

    WeareinthemiddleofclosingdowntheV2ofthe…