8

In C#, the DateTime property Month has a type of int (a 32 bit signed integer) yet its range will only ever be 1-12. What are the reasons the C# team chose int over a smaller numeric type such as byte(8 bit unsigned integer)?

  • 5
    Unless someone from the C# design team is lurking I'm not sure you'll get an answer to this... – Liath Sep 19 '18 at 14:13
  • 1
    @Liath that won't help I'm afraid, see Is asking “why” on language specs still considered as “primary opinion-based” if it can have official answers? (incidentally, an explanation from C# language designer) – gnat Sep 19 '18 at 14:46
  • Btw DateTime as implemented in CoreFX encodes the time as a single 64 bit value. Informations like days or months are extracted from that value via some clever math (GetDatePart()). This is not a reason for using an int as return value, it just has no drawbacks. Note also that due to alignment issues, returning a byte from a function won't be more efficient than returning an int. – amon Sep 19 '18 at 14:51
  • 3
    I'd be tempted to ask why it isn't a type called Month. – bdsl Sep 20 '18 at 9:15
  • Most probably it is because the operations performed internally required an int, and the compiler designers decided that it is not worthwhile converting it to something else, probably for performance reasons. – NoChance Nov 1 '18 at 15:58
22

int is used for almost all integer variables in .NET although often a smaller type would be enough. Also, unsigned types are almost never used although they could be.

Some reasons:

  1. Signed and unsigned types as well as integer types of different size can be awkward when combining them (+ or < for example). The rules are not obvious. I'm an experienced developer and I could not tell you the full set of rules. I do not need to know.
  2. int is fast on all common architectures. Smaller types often result in conversions which can be slower.
  3. Performance is not an issue for 99% of typical code. No need to overthink this. Just use int everywhere.
  4. Readability is very good because the intention is clear. A byte would suggest binary data for example. (See comment by Flater.)

It's a useful convention to use int.

  • Thanks, these are some great reasons. I never thought about the performance implication of converting from small to large or unsigned to signed, as that is all implicit in the code. – Frayt Sep 19 '18 at 14:53
  • Yes I actually made code slower once by using bytes instead of ints, just use ints ;+) – Joel Harkes Sep 19 '18 at 19:38
  • 1
    Another factor might be that "everyone actually prefers int by default" and the designers wanted no type mismatch surprises. – S.D. Sep 20 '18 at 5:20
  • 1
    Adding to an otherwise complete answer, readability is another reason to use int. If I saw a byte property, I wouldn't automatically think that it's a numerical value. A byte can be many things (e.g. a compacted collection of booleans). Pushed a bit further, I doubt anyone would look at a byte[] and thinks to themselves "aha, that must be an optimized List<int>". – Flater Sep 20 '18 at 6:54
  • 2
    Point 3 contradicts point 2 in this answer. Probably a better "point 3" would be "For 99% of typical code, the memory overhead of "months as int" vs "months as bytes" is not an issue. – Doc Brown Sep 20 '18 at 11:47
4

A month is not a value. A month is just a month.

The 1-12 mapping (which should have been 0-11 imo) is only made to make it easier to do math with it.

And once you start doing math with it, you have to be pragmatic. Ints are the defacto default for integer math. So use those.

It's what programmers expect. Without context: expect an int.

Because you're not interested whether January is 1 (or 0), you are interested in answers to questions like: "how many monthly installments till I paid of this debt". And then you find out that you should have used the integer instead of byte.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.