A twist of lemon

I was browsing the archive of design notes from the early days of the C# language the other day. Apparently whoever was editing the notes back then had a sense of humour. (UPDATE: It was Scott, just as I suspected.) I stumbled across this note from May 1999:

We considered a proposal to rename short, int, and long to short, tall, and grande. More thought on this issue is required; we will revisit this issue on Friday.

And yet the notes for the following Friday say nothing of it. Someone dropped the ball.

Why only address the number types? Let’s solve the big problem and make the language skinnable. Now you can have C# look like C, Java, Assembler, or Malbolge. You can have Easter, Halloween, and Christmas skins. You can download the .NET 5.0 skin before the release of .NET 4.0. This would really open the door to a world of unlimited possibilities.

I kinda woulda been ok with the exceedingly-boring bool, char, int8, int16, int32, int64, float32, float64. I’m sure types like byte, short, int, long, float, and double make some programmers feel right snuggly and warm as if they were home at last, but the sense of security backfires the first time you try to match native code’s LONG against c#’s long in a P/Invoke signature. And trying to explain to a non-C developer what a double is a double of, and what a long is longer than, and what a short is shorter than. Floats and ints are tricky enough already. No need for coffee to add to the confusion.

> I kinda woulda been ok with the exceedingly-boring bool, char, int8, int16, int32, int64, float32, float64. I’m sure types like byte, short, int, long, float, and double make some programmers feel right snuggly and warm as if they were home at last, but the sense of security backfires the first time you try to match native code’s LONG against c#’s long in a P/Invoke signature. And trying to explain to a non-C developer what a double is a double of, and what a long is longer than, and what a short is shorter than. Floats and ints are tricky enough already. No need for coffee to add to the confusion.

Well, the type names aren’t just C by now. It’s also C++ and Java at least, and then there are plenty exotic languages using them, such as D.

Yeah, I always found "float" and especially "double" cheesy terms (why oh why did they kill pre-existing "long float" when writing ANSI standard for C? it made perfect sense…), but by now there’s over 30 years of history with those two; and with "short" and "long", over 40 (Algol-68). Trying to find a better replacement is like doing the same for "heap" or "hash". It’s just not worth it.

int32 – given how often it is used, it would be quite a handful to type. I wouldn’t mind just int for that (and it matches the usual C++ meaning, too), with int8/16/64 for the rest of them. It’s actually how F# does that – you get two shorthands, int=System.Int32, and float=System.Double. And then you have int8/int16/int32/int64, the u-prefixed unsigned varieties, and float32/float64. Makes sense… just not in a curly braces family language.

All that said… it’s not like you can’t use System.Int32 and friends directly in C# if you really want clarity. So if you have problems with matching P/Invoke sigs, make it a rule that you only use full integer type names – such as Int32 – in them, and never keywords.