Add U8320 and U12288

[Fethbita]

In #228 and #229 extra sizes up to 8k were implemented. In some usages, we need the extra sizes to go up to 16k (for example when two 6k numbers are multiplied).

For our use-case U12288 and 8320 in addition to extra-sizes would be enough, but for completeness, I added all values in 64 bit increments to a new feature extra-sizes-16k.

Let me know if you would rather prefer if we only add these two extra-sizes we need to extra-sizes feature.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 79.87%. Comparing base (9cbea3a) to head (3c75f05).
⚠️ Report is 1 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #1007   +/-   ##
=======================================
  Coverage   79.87%   79.87%           
=======================================
  Files         163      163           
  Lines       17593    17593           
=======================================
  Hits        14053    14053           
  Misses       3540     3540           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[tarcieri]

I don't think it makes sense to just keep adding sizes indefinitely. The type aliases are mostly for convenience. The core implementation is const generic.

What are you actually using them for? Can you just define your own type aliases?

[Fethbita]

Yeah, it makes sense. I use U12288 for 6k*6k operation and U8320 for 8k*128 operation. I could define my own type aliases but impl_uint_aliases and impl_uint_concat_split_even macros are not exported. How would you recommend I do it?

[tarcieri]

We could potentially export them.

Otherwise it’s just type Foo = Uint<{ nlimbs!(12288) }>;

[fjarri]

It is not exactly equivalent since some traits involving size modifications are implemented only for size aliases (Split, Concat, RemMixed etc)

[Fethbita]

Indeed, even if I made the impl_uint_aliases and impl_uint_concat_split_even public, then there are other things that must become public:

error[E0603]: module `traits` is private
   --> /tmp/crypto-bigint/src/uint/macros.rs:92:22
    |
 92 |         impl $crate::traits::ConcatMixed<Uint<{ <$name>::LIMBS / 2 }>> for Uint<{ <$name>::LIMBS / 2 }>
    |                      ^^^^^^ private module
    |
note: the module `traits` is defined here
   --> /tmp/crypto-bigint/src/lib.rs:214:1
    |
214 | mod traits;
    | ^^^^^^^^^^
help: consider importing this trait instead
    |
 92 -         impl $crate::traits::ConcatMixed<Uint<{ <$name>::LIMBS / 2 }>> for Uint<{ <$name>::LIMBS / 2 }>
 92 +         impl crypto_bigint::ConcatMixed<Uint<{ <$name>::LIMBS / 2 }>> for Uint<{ <$name>::LIMBS / 2 }>
    |

Instead, I changed the PR to only add the 2 types that I need, if that it okay.

[tarcieri]

Perhaps we should address #793 as an alternative?

I would prefer to avoid having to start adding a bunch of bespoke sizes for various use cases. We do that in hybrid-array by necessity since there's no alternative, and it carries a high maintenance burden, and at least there slows down the compiler whenever we add more impls.

[Fethbita]

#793 looks like a good suggestion, but I don't think I could implement it here as I am not that familiar with traits and generics.

[fjarri]

I suppose I could. Completely forgot I even filed that issue.

[tarcieri]

@fjarri that'd be great

[fjarri]

Would you rather I replaced the existing traits, or added another set?

[tarcieri]

I’ll leave that at your discretion, but if we could minimize the total number of traits that’d be great

[fjarri]

Started #1008

[tarcieri]

This should be obviated by #1008