[Feature Request] Incorporate u128/i128 to stdlib

[willemneal]

Many AS projects currently use as-bignum in their programs for 128-bit integers. Other languages like Rust have added them to their standard library.

My concern is as projects and tooling grows libraries could rely on different versions of as-bignum and given it's importance there should only be one source of truth. Furthermore, I've already ran into the issue of types clashing because of two different versions being in the same project, e.i. the compiler complained that one type cannot be cast to the other because they had different locations.

I know the goal of the stdlib is to provide the same API as the JS stdlib, but in this case I advocate for adding it as a first class number is the language.

[MaxGraey]

I have this plan for AIR (middle IR) which also allows optimize u128 / i128 the same as usual integer types (on binaryen side).

[willemneal]

Would you be opposed to moving the current implementation to the stdlib in the meantime?

[dcodeIO]

I am skeptical here for a few reasons:

• This is not a primitive data type but requires allocation under the hood, so it's really more a class. Should probably not mix that with u64 etc. to avoid wrong assumptions.
• We don't know what Wasm will do in the future. Say, for instance, there'll be a proposal for an i128 primitive type one day, then that'd give us a stdlib problem that would have been avoidable.
• When we start adding custom classes to stdlib, where do we draw the line for others? StaticArray is already borderline.

[MaxGraey]

This is not a primitive data type but requires allocation under the hood, so it's really more a class. Should probably not mix that with u64 etc. to avoid wrong assumptions.

with multi-values it's not necessary

[dcodeIO]

Doesn't change the status quo, though. I certainly do understand the desire, and I am fine with leaving this issue open until an informed decision can be made, of course. But right now I am skeptical.

Potential paths forward could be:

• Wasm adds an i128 type
• SIMD becomes available everywhere and we find a way to repurpose v128
• We manage to figure out a good story for multi-value in this context

[MaxGraey]

agree. First of all we need a typles over multi-values which btw already supports everywhere

[willemneal]

We don't know what Wasm will do in the future. Say, for instance, there'll be a proposal for an i128 primitive type one day, then that'd give us a stdlib problem that would have been avoidable.

If the API changed and we couldn't map our API to the new one in the implementation I agree that that will be an issue. Perhaps we should consider using the same API as Rust as I'm sure that will be taken into consideration when/if the Wasm standard adopts it. Furthermore, I think that users will expect breaking changes with certain Wasm features.

The current number types do have a backing class so users that use instanceof should not see a breaking change.

As for Max's point, a lot of users will use older VMs so it would be a while before we could offer it as a standard feature. (we could pollyfill multi-value of course). Users of as-bignum already expect an allocation for the classes so I don't see that as an issue.

Perhaps adding it could be considered a "nightly" feature that could break and change. This way users can start to use it with that expectation until it hits stable. I know we had spoke earlier about having the two versions and it wasn't perceived well, but assemblyscript-nightly could be published from another branch. I also thinking having the nightly would encourage community members to build stuff without worrying if it will end up in the stable branch. It is also important if we want to scale up development as multiple features could be worked on at once and tested in the field.

Or even without nightly we could just produce a warning that the feature is not stable as it's an opt-in import.