Naming convention for APIs in the 64 bit world

style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">We are having a little debate
internally on an issue around naming conventions for moving APIs to the 64bit
world.   ns = "urn:schemas-microsoft-com:office:office" />

style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">We made a few design mistakes in V1
and exposed some properties that are really word sized as Int32’s rather than
Int64s.  I don’t think there are
very many of these, but it seems we need a common pattern for any we do dig

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

style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Here is an example. style="mso-spacerun: yes">  On the Process class today we
style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: 'Courier New'">public
VirtualMemorySize { get;

style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: 'Courier New'">public
int WorkingSet
{ get; }

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

style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">As you know we can’t just change
these to return longs as that would break apps complied against V1 or V1.1 when
run on Whidbey…  We also can not add
overloads that return longs as the properties must differ by more than return
type (btw, this is a CLS rule not a runtime rule, the runtime is just fine with
overloading on return type.. now the only problem is finding a language where
that is valid ;-)).  So we are left
we having to make a name change…

style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">We feel strongly we want a postfix
so the properties sort correctly in initellisense. style="mso-spacerun: yes">  style="mso-spacerun: yes">  The two front runners

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

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

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

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

style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: 'Courier New'">public
VirtualMemorySizeLong { get;

style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: 'Courier New'">public
WorkingSetLong { get; }

style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: 'Courier New'"> 

style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Or style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: 'Courier New'">

style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: 'Courier New'"> 

style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: 'Courier New'">public
VirtualMemorySize64 { get;

style="FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: 'Courier New'">public
WorkingSet64 { get; }

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

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

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


Comments (42)

  1. RichB says:

    Returning a long is exactly the same problem as returning an int. When the CLR goes 128bit you will have the same problem. Now, of course we can never envisage a situation where computers have outgrown 64bits – but it has happened before.

    Surely it would be better to use IntPtr or some other variable sized integer type?

    ps I prefer the ’64’ suffix.

  2. Len W says:

    I agree with RichB that some kind of ‘native type’ struct is needed for something like this. I also think it would be forgiveable to break existing code in order to fix the problem you mentioned.

    On another note, I would very much like to see co-variant return types in a future version of c#.

  3. S N says:

    Since it was already decided to use long rather than 64, why do we need to create a confusion over another confusion.

    What I mean:-) V1.1: Array.LongLength ……………………….

  4. Neil Cowburn says:

    I would prefer a ’64’ suffix.

  5. Pete says:

    Correct me if I’m wrong, but aren’t int and long just synonyms for Int32 and Int64 (which are the official names)? In which case it seems to me that WorkingSet64 fits in a lot better. It’s also a lot more descriptive than WorkingSetLong.

    On a side note I would really like to see property overloading in a future C# version. Not necessarily overloading on returns types everywhere — just properties. Otherwise it’s one more reason to ignore them in the face of the superiority of methods (for this type of versioning).

  6. Pete says:

    In fact now that I think about it, isn’t it also true that .NET languages must have Int64, but not long? It would be weird calling SomeFuncLong from a language that has no actual "long" concept.

  7. +1 on Xxx64. Given the address space that 64 bits gives us, the CLR will be history long before we need to move to 128 bits.

    Alternatively, how about ‘VirtualMemorySizeEx2’? 😉

  8. marco says:

    if the return type has to be long then the function name must be VirtualMemorySizeLong. But long it’s 64 bit for 64 bit platforms and 32 bits for others, so the developers could always use the VirtualMemorySizeLong method and you internally can call either the 32bit or the 64bit one.
    And speaking of future compatibilty when we will have a 128bit processor, long will be 128bit long and so we will not have the issue of adding another method.
    If the new function must only be called within the 64bits environment, then the return type should be int64 and the postfix in the xxx64 notation.

    That’s my 2 cents.


    – mn

  9. Rob Walker says:

    +1 on Xxxx64. As a C++ programmer I’ve been bitten before by the long==64 bits in C#. Having it spelt out always helps.

  10. Zhwgnon Flrq says:

    I too agree with Rich (and Len)
    Break existing code. Create a new struct type – maybe in the System.Environment namespace called Word.


    public Word VirtualMemorySize { get; }
    public Word WorkingSet { get; }

  11. I am confused by the benefit of side by side execution if all older apps must be able to run on newer frameworks.. Wasn’t one of the big design goals of side by side execution to allow breaking changes in the framework to not affect older apps? It seems like the .NET framework would evolve much better if it is assumed that apps written for 1.x will run on a 1.x CLR and apps written for 2.x will run on a 2.x CLR. Maintaining compatibility throughout all possible versions of the .NET framework will still not eliminate the compatibility issues and we’ll also end up with the VirtualMemorySizeEx2 problem mentioned above.. Why not ship the 1.1 framework with Longhorn in addition to the Whidbey framework?

  12. Marcus says:

    My vote is for the "64" suffix. 64 explicitly states the size is less to type.

  13. "And speaking of future compatibilty when we will have a 128bit processor, long will be 128bit long and so we will not have the issue of adding another method."

    That’s not true. The sizes of the types are fixed. If, for god only knows why, we have a 128-bit machine, then new types will have to be invented to cover the need for 128-bit integers.

  14. MartinJ says:

    Another issue is that FxCop doesn’t like the type to be embedded in public property names. So, VirtualMemorySizeLong will report a violation. But, VirtualMemorySize64 won’t.

    Guess which one I’m voting for.

  15. Eric Gunnerson says:

    64 is a beter choice, esp since in C++, ‘long’ is 32 bits.

  16. Pete says:

    marco: "if the return type has to be long then the function name must be VirtualMemorySizeLong".

    But the return type isn’t long, it just looks like it. It’s actually Int64.. so surely VirtualMemorySize64 makes more sense.

    Zhwgnon: "Create a new struct type – maybe in the System.Environment namespace called Word."

    But wasn’t the whole point of the common type thingy that each separate type has a specific size?

    The concept of supporting 128 bit numbers might also be a valid issue. After all, we support 64-bit variables on 32-bit machines. What would it be then, VirtualMemorySizeLongLong? Or VirtualMemorySizeReallyLong? 🙂

  17. marklio says:

    Another vote for 64 based on there being no "Long" in the class library.

  18. R says:

    Func64() looks much better. No confusion (which might happen with FuncLong()). – I wish I could stop calling them funcs.

    Whoever suggested the following …
    public Word VirtualMemorySize { get; }
    public Word WorkingSet { get; }

    No, no, no, no … please no.

  19. Anonymous says:

    Why, why, why, why … please why?

  20. chris says:

    break code. let side by side execution take care of it.

    the other implicit problem with WorkingSet/WorkingSet64 is that it introduces a subtle error… for example

    lets saytheres a property called Size, which is int32. Lets say i do something ridiculous, like say that the maximum size is int32.MaximumValue. lets say i then say sizePercent = Size/int32.MaximumValue.

    Now, theres this new value, size64. for all values of size <int32.MaximumValue, size==size64. but, when size64 exceeds int32.maximum value, the value of "size" (the int32 version of the property) is wrong. so, my percentsize calculation will also be absolutely wrong.

    essentially, your supporting the use of two different properties to represent the same logical information, and ensuring that one of those properties will return incorrect information, and forcing developers to change code to get correct information in those cases.

  21. Corrado Cavalli says:

    My vote goes to 64,
    1st- It’s shorter
    2nd-It clearly indicates the type size
    After many years using VB I still have a little brain lock remembering how many bytes Integer or Long is, that’s why I always use Int32 or Int16 instead of integer or short.

  22. Dhominator says:

    +1 for neither.

    Posted rationale for 64 suffix is silly… "I can’t remember the size of the type?". Well, you not supposed to have to.

    Suffix of Long is only marginally better (at least it’s not bit size). But it’s ugly… and it breaks current coding convention.

    This is a horrible design pattern that should not be propagated. Fix the problem, force load of v1[.x] for older apps.

  23. +1 for Neither,
    However if you are convienced that you have to suffix them than I vote for "64" as it is consistant with Int32 and Int64

  24. Klaus RM says:

    One more vote for xxxx64. Int32 and Int64 shows the way.

  25. Anonymous says:

    +(10^666)! for Word.

  26. Shane King says:

    Modify the .NET platform to provide the overloads transparently.

    A 1.x app will see only the 32 bit version
    A 2.x app will see only the 64 bit version

    That way you can maintain backwards compatability and not break any CLR rules and not have any ugly names.

    Plus it would be a generally useful feature to have – the ability to mark a method as only being callable from code of certain versions. That way you could deprecate methods to new source, but maintain the methods for old binaries. All without the mess of worrying about forcing the load of older versions.

  27. Maciek says:

    My favorite solutions in that order:
    1) Add support in CLS for overloading on return type. C++ has it already.
    2) Break compatibility and let SxS execution deal with it
    3) use 64 suffix. Languages as MC++ use long for Int32, so using Long as sufix would lead to a lot of confusion.

  28. Lars Jonsson says:

    public double VirtualMemorySize { get; }
    public double WorkingSet { get; }

    Why on earth do you need more than 15 significant digits when dealing with memory sizes? They are approximations anyway.

  29. +1 for: Let side by side runtime do it’s work. Stop trying to get everything in the same namespace, it’s going to be a REAL mess if you do that.
    And provide a compatibility layer if you really want applications to run on 2.0 when compiled against 1.0. Aliasing works just fine for that kind of situations, you get a cleaner lib. We all loved the clean 1.0. If you start (as it’s being done in other teams) to do]

    I’m pretty sure the runtime is going to loose a LOT to that. A huge lot.

  30. Alexander Kogtenkov says:

    It’s better to rely on SxS execution to avoid polluting the system with more and more legacy names.

    BTW, such platform-dependent things can be explicitly specified as being platform-dependent: use UIntPtr and mark them as not CLS-compliant. Then the clients will know that they are touching dark areas of the API.

  31. Ole Thrane says:

    +1 for side by side.
    Keep the API clean!

  32. Pete says:

    Err.. doesn’t side by side execution mean we have to recompile our apps separately for 64-bit machines and 32-bit machines? Since the data types we’ll be using are set to 32 or 64 bits in the compiled code?

    What happens if I have an Int64 which I want to assign to WorkingSet (or whatever, assuming the property is setable) and it turns out that the runtime I’m using is the 32 bit version? If I’d set it to WorkingSet64 it would have been fine (I assume there will be a version of WorkingSet64 for 32 bit machines? Or the framework would be equally broken).

  33. R says:

    R Said – "Whoever suggested the following …
    public Word VirtualMemorySize { get; }
    public Word WorkingSet { get; }
    No, no, no, no … please no."

    Why not? What’s a word? Whaddaya mean it’s not obvious?
    Case closed.

  34. Keith Hill says:

    +1 for letting side by side handling this.
    I am all for binary backwards compatibility and not breaking existing programs. However source compatibility is a different story. At the point I recompile my program, I would actually like to know that any call to VirtualMemorySize no longer work because the return value doesn’t fit into an Int32. To me, that is a feature. I can fix my code to handle the return value as an Int64.

    Personally I really despise the ClassName2, ClassNameEx, ClassNameEx2 approach to naming updated types. That just really screams to me "hey, we screwed it up and now we are fixing it" or "we screwed, fixed it once but screwed up doing that so we have to fix it again (Ex2)". That doesn’t make me feel confident about the Framework.

  35. Anonymous says:

    I think a couple other people suggested the xxxInt64 version as it is the suggestion standard for class library design provided by Microsoft. It basically tells class library desiners to use the native .NET names for data types so that you do not get cross-language confusion.


  36. Justin says:

    Xxx64 ++;

    definately should include postfix/suffix annotation to keep the CLS/FCL clear — especially for those who use .Net languages that consider ‘long’ to be a 32-bit type. possibly allow it to be aliased to ‘XxxLong’ when targeting 64bit machines at either the source-level (and let the compiler inject the much more descriptive CLS/FCL ‘Xxx64’ type) or IL-level.

  37. Anonymous says:

    If there is absolutely no way to avoid adding methods with ‘we screwed up’-names, then you should definately use the CLR type names and not the C# ones.

    And how about using namespaces for new types like XmlDocument2. System.Xml.Whatnot.XmlDocument sucks less than System.Xml.XmlDocument2. And face it – type names with version number postfixes suck bigtime.

  38. ShadowChaser says:

    I wouldn’t worry about naming – I would break backwards-compatibility for assemblies compiled on the new framework.

    Yes, it’s a minor annoyance for people to need to fix their code, but in my opinion, providing two sets of functions is making the problem even worse!

    If I *had* to choose, I would pick 64. "long" is meaningless.