Maybe we can use 64 bit integer for dictionary counts

[Xyncgas]

Unfortunately, I want my code to be historically correct and Dictionary's Count property won't let me
So in case when I am long gone after getting hired, the number of elements in my dictionary became more than Int32.MaxValue, my reputation doesn't just go down the drains
Because the requested count is always going to be 64 bit integer I do want my dictionary to hold more items than a 32bit integer

[Clockwork-Muse]

.... At the scale where you'd actually have that many elements, you're - usually - looking at dedicated database types and interfaces (note this isn't necessarily "SQL Database", but something purpose-built).

That aside, this would be a (fairly major) breaking change - especially since you'd probably have to do the entire collections namespace (since the property actually comes from IReadOnlyCollection).

[Xyncgas]

Often, I see people commenting "but it's impossible that you have this/that reason to do it" whenever a method was proposed

In reality I actually don't store that many objects but the addressable space of 64 bit integer is provisioned into several pieces and then those pieces are then provisioned again so you end up using only a little bit of the space if that makes sense, so when you do this n times you now have 2^64 - 2^n numbers of elements addressable, and if I may be real here, after creating 16 nested folder I now have 2^16 addressable space with 32 bit int which isn't a lot while 64 bit integer allows me to make another 32 nested folder, which at the end of the day can contain 2^16 = 65536 files which isn't a lot

[Clockwork-Muse]

.... That doesn't seem to be relevant to the actual Dictionary type at all, much less the Count property...?