Biginteger literal type and "bigint" alias

[fanoI]

I propose to add 'I' (as in F#) as a literal biginteger type giving in this way the possibility to declare it as any numerical type (without the need to use TryParse() or obtaining the bignum via computation).

For example:

BigInteger big1 = 12345678901234567890123456789I;
BigInteger big2 = big1 + 42I;

As in F# to make it feel as a normal int type, the "alias" bigint should exist.

[jnm2]

I'd prefer the suffix BI for BigInteger and BR for BigRational.

[DavidArno]

@jnm2,

Does a different opinion on which suffix to use, really justify a downvote?

[jnm2]

I don't see the value of this. Making types "feel" like primitive types is not a worthy goal unless there's some productivity or performance benefit. Even DateTime which is used three or four orders of magnitude more is not treated as a primitive, so why BigInteger?

[fanoI]

Because it is an integer type and so it feels normal to create a new one doing:

BigInteger big1 = 12345678901234567890123456789I;

than doing:

BigInteger big1 = BigInterger.Parse("12345678901234567890123456789");

the fact of using 'I' is simply because there is a precedent in F#, I'm unsure 'BI' could be used being of two characters as literal.

[jnm2]

Because it is an integer type and so it feels normal to create a new one doing:

That's my point though. I really don't think "feel" is an important enough basis to justify the complexity and work of this language feature.
As far as feel, you are still doing a parse and to me it feels better and more transparent to say "Parse," but either way, I don't think feel is important enough on its own with no other benefits. I also don't think BigInteger is used even a fraction as much as DateTime, another primitivey type.

the fact of using 'I' is simply because there is a precedent in F#, I'm unsure 'BI' could be used being of two characters as literal.

We have UL.

[HaloFour]

Decimal is treated like a primitive type, though, so there is precedence.

The compiler wouldn't have to resort to BigInteger.Parse. It could use any of the other constructors which best match the literal.

However, I think there should be a substantially high bar for promoting any type to a "primitive". It involves officially enshrining the type within the C# specification. The fact that BigInteger doesn't live in mscorlib immediately gives me pause. Then there is whether said "primitive" should have support extended elsewhere in the language, such as default values of arguments, which C# currently does fake for Decimal via an attribute.

[jnm2]

Decimal is treated like a primitive type, though, so there is precedence.

I almost referenced decimal as an example of why promoting arbitrary types to primitive status isn't exactly amazing. :D

[fanoI]

Doing:

BigInteger big1 = 12345678901234567890123456789I;

the parsing will happen at compile time not at runtime!

It would be the same thing that declaring an Int32 in this way:

int anInt = 42;

does parsing to convert "42" in 42... so why we do not always do:

int anInt = int.Parse("42");

why then in F# they did this without problems and in C# could not be done?
How F# has solved the presented issues:

1. The fact that BigInteger is not in mscorlib
2. A BigInteger in F# could be used as a default value?

The first point I think would be solved giving the possibility for a type to define its literals so there is no need to extended the language to do this, the second point effectively is a big problem... from the user of the language point of view the fact that I cannot do this does not make a lot of sense (I was a little deluded that I could use "Color.Black" as a default value... it is a "number" for me that too so why not?).

[DavidArno]

@jnm2,

Thanks for the clarification. Whilst I see benefit to the literal proposal, I'm with you and @HaloFour in not really seeing any benefit to a bigint alias. Just use var...

[HaloFour]

@fanoI

the parsing will happen at compile time not at runtime!

It would be the same thing that declaring an Int32 in this way:

Not quite. Integers are a CLR primitive, loading them involves a completely different set of IL opcodes. Yes, the compiler parses the text that is "42" and from that emits ldc.i4 with 42 as a 32-bit constant.

For BigInteger the compiler would have to parse the text and come up with some representation that can be passed to the constructor of BigInteger. There's only two ways for the compiler to do this with arbitrarily-large BigInteger literals. One way is to simply sanitize the literal text and call BigInteger.Parse, which forces the compiler to take direct dependencies on a number of other types within the BCL such as IFormatProvider so that the text can be parsed in a deterministic and invariant manner. The other way for the compiler to do this with arbitrarily large literals would be to emit a byte[] of the internal state of BigInteger and pass that to the non-CLS constructor that accepts that byte[].

This is effectively how the C# compiler handles System.Decimal literals. That type offers a constructor which accepts the raw state as 3 ints, a bool and a byte and the C# compiler parses the literal string and converts it to those 5 arguments:

decimal d = 123456789012345678901234.567890m;
// actually
decimal d = new System.Decimal(1849262357, 1186908593, 669260594, false, 5);

How F# has solved the presented issues

I believe that F# has a lot more leeway regarding language design decisions. While the F# language spec is public it's not expected to be ECMA/ISO standardized as is the case with C# (despite being a few versions behind in that respect). As a functional language F# also targets a different crowd where large math is a more common situation.

To note, I'm not opposed to the idea, I'm just laying out what I think are issues that need to be considered.

[CyrusNajmabadi]

I looked into this ages ago. The primary reason i found that this was not worthwhile was that:

1. BigInteger itself was not wildly used. So this feature wouldn't really benefit that many.
2. When BigInteger was used, literals were not very common. i.e. people would do lots of math with it, but would very rarely actually have to create a new BigInteger value from some known literal.

As such, there was extremely little gain to doing this since users could just write BigInteger.Parse. IMO, we should make things part of the language when we can at least reasonably expect many to use it, or if it would provide substantial value to the people currently using it*. I'm skeptical with BigInt that that value exists.

--

• Note: after all this time, I def feel that even 'decimal' might not have deserved to make the cut. But there are some areas where people use them extensively, and do use literal values a ton. So i can see how it was nice for them. But that's for decimal, and i would guesstimate that BigInt is several orders of magnitude lower in usage.

[chergey]

DateTime could also be given opportunity to be declared in some way but we would have to supply format option, perhaps something like: DateTime dt ="10.8.2017" : "dd.m.yyyy". Looks ugly (syntax isn't so important) but feels better to me than DateTime(..many arguments..)

[AdamSpeight2008]

Also it would tie the project to a specific version of the framework, .net 4.0. With little, if any way to make it compatible with earlier version.
DateTime is a "primitive type" in VB.net #2017/03/15#

[jnm2]

@elcergey I'm doubtful that anything is more readable than new DateTime(yyyy, mm, dd). I certainly never write dates in any other order whether typing or writing.

[ufcpp]

I'd prefer more generalized features:

• User-Defined Literals
  • also applicable to:
    • Regular Expression Literals
    • DateTime
  • This might have to be implemented by expression-level or statement-level source generator
• Const Binary Data
  • [Proposal] primitive struct as primitive roslyn#16095 (comment)

BigInteger big1 = 12345678901234567890123456789I;

↓ a source generator

const byte[] big1Value =
{
    0x15, 0x81, 0x39, 0x6E, 0xB1, 0xC9, 0xBE, 0x46, 0x32, 0x1B, 0xE4, 0x27
}; // embedded in the User String matadata table
var big1 = new BigInteger(big1Value);

[chergey]

@AdamSpeight2008 As if someone is using anything below .NET 4.0 nowadays.

[AdamSpeight2008]

@elcergey Feature tend to target a minimum language version. not framework version.

[fanoI]

@ufcpp surely this could be part of the more generic discourse of "custom literals" in the sense that will make possible to define literals without the need to change the C# language, BigInteger could have the literal defined in this way.

[DavidArno]

@AdamSpeight2008,

That's not always true though. For example, value tuples cannot be used with frameworks prior to 4.0 (or maybe 4.5; read conflicting details on this and haven't bothered to test it myself).

[chergey]

@DavidArno Same goes for lamdas, expressions and so on. Need to test tuples though.

[Thaina]

I would also love to have BigFloat (a struct of bigint and big mantissa). And also Rational being suffixable

[lloydjatkinson]

While we're on the subject, a Numeric base type or interface for numerical types would be pretty nice.

[louthy]

@lloydjatkinson The problem with that is it causes boxing on value-types. Which is why I assume they didn't have an INumeric interface originally. The new proposals for shapes will resolve this. But you can do ad-hoc polymorphism in C# now to achieve the same effect:

    public interface Eq<A>
    {
        bool Equals(A x, A y);
    }

    public interface Ord<A> : Eq<A>
    {
        int Compare(A x, A y);
    }

    public interface Semigroup<A>
    {
        A Append(A x, A y);
    }

    public interface Monoid<A> : Semigroup<A>
    {
        A Empty();
    }

    public interface Num<A> : Ord<A>, Monoid<A>
    {
        A Plus(A x, A y);
        A Subtract(A x, A y);
        A Product(A x, A y);
        A Divide(A x, A y);
        A Negate(A x);
        A FromInteger(int x);
    }

    public struct TInt : Num<int>
    {
        public bool Equals(int x, int y) => x == y;
        public int Compare(int x, int y) => x.CompareTo(y);
        public int Plus(int x, int y) => x + y;
        public int Subtract(int x, int y) => x - y;
        public int Product(int x, int y) => x * y;
        public int Divide(int x, int y) => x / y;
        public int Negate(int x) => -x;
        public int FromInteger(int x) => x;
        public int Empty() => 0;
        public int Append(int x, int y) => Plus(x, y);
    }

    public struct TDouble : Num<double>
    {
        public bool Equals(double x, double y) => x == y;
        public int Compare(double x, double y) => x.CompareTo(y);
        public double Plus(double x, double y) => x + y;
        public double Subtract(double x, double y) => x - y;
        public double Product(double x, double y) => x * y;
        public double Divide(double x, double y) => x / y;
        public double Negate(double x) => -x;
        public double FromInteger(int x) => (double)x;
        public double Empty() => 0.0;
        public double Append(double x, double y) => Plus(x, y);
    }

Then you can write generic functions that take Num<A> constrained arguments:

    static A Double<NumA, A>(A x) where NumA : struct, Num<A> =>
        default(NumA).Plus(x, x);

When you call it you specify the instance (TInt, or TDouble):

   int x = 100;
   double y = 50.0;

   var r1 = Double<TInt, int>(x);
   var r2 = Double<TDouble, double>(x);

No boxing, no additional memory allocations (default(NumA) is optimised out in a release build).

A more complete implementation can be found here with the instances (TInt, TDouble, etc.) already build for all core types.