Feature request: Add Environment.LongTickCount

[geoffkizer]

Environment.TickCount rolls over, which makes it inconvenient to use. See e.g. dotnet/corefx#35401

To remedy this, we should add Environment.LongTickCount. This is trivial to implement on Windows using GetTickCount64.

public static class Environment
{
    public static long LongTickCount { get; } // or TickCount64
}

[stephentoub]

Related https://github.com/dotnet/corefx/issues/3249

[danmoseley]

There is precedent for adding 64 on properties on Process eg

        public int PeakWorkingSet { get { throw null; } }
        public long PeakWorkingSet64 { get { throw null; } }

also ContentLength64 on a couple networking classes. Altogether I see 11 public properties in CoreFX with the 64 suffix.
Conversely the only example of the Long prefix is

    public abstract partial class Array 
    {
        public int Length { get { throw null; } }
        public long LongLength { get { throw null; } }
   }

So it's worth considering

public static class Environment
{
    public static long TickCount64 { get; }
}

[stephentoub]

Conversely the only example of the Long prefix is

There's also Enumerable.LongCount.

But I'd be fine with either the Long prefix or the 64 suffix.

[danmoseley]

There's also Enumerable.LongCount.

Right I only looked at properties

[tannergooding]

I think 64 or Int64 makes much more sense.

The framework guidelines also recommend not using language specific names (like Long), given that they can mean different things in different languages: https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/general-naming-conventions#avoiding-language-specific-names

[jeroen-mostert]

Re: language-specific names, my favorite bug/gotcha in this regard is IDataReader.GetFloat() (which should have been IDataReader.GetSingle()). This has bitten numerous folks who thought to use .GetFloat() to read a T-SQL FLOAT, which is actually a double-precision type and has to be read with .GetDouble(). This is practically an unavoidable mistake if your language doesn't have a float type in the first place (e.g. VB.NET).

The only reason "long" is halfway acceptable in this regard is because it can be interpreted as a modifier rather than a type name (e.g. LongLength is Length, but "longer") and so is unlikely to be as harmful as the above.

[terrajobst]

The most logical API proposal would be, which looks fine to me.

public static class Environment
{
    public static long TickCount64 { get; }
}

I'll bring it up in the next API review.

[terrajobst]

Video

And we landed on:

public static class Environment
{
    public static long TickCount64 { get; }
}

[danmoseley]

Should we mark up for grabs or is someone planning to take this?