Publicly export a macro to define `Uint` and associated sizes

[kayabaNerve]

I have the edge-case of having to work with ~5k-bit unreduced numbers, taking their product (~10k bits), just to perform a division. While I was writing an issue discussing wrapping_div_wide (following the existence of rem_wide) to optimize this edge case of mine (and be more flexible with the allowed types), I think the most practical solution and one which resolves many historic issues (#1095 for the current iteration) would to be let users define their own Uint type with the sizes their application needs. This would be with the expectation that crypto-bigint provides the necessary glue via a mixture of traits, literal implementations re: UintRef, and literal implementations in the macro-generated code.

This would mean application-specific Uint type definitions and application-specific invoking of impl_uint_concat_split_mixed, shifting long compile times to the user, but also allowing them to tailor to just their subset (improving compile times).

Alternatively, we can continue to wait for the necessary const generics, or someone could probably write a third-party crate which is Uint around hybrid-array to achieve similar results for more flexible Uint types?

[tarcieri]

rust-lang/rust-project-goals#100 might be able to address some of the issues, though I guess we can consider re-exporting the macros as a sort of stopgap, maybe with #[doc(hidden)] so they don't clutter the rustdoc.

[kayabaNerve]

I'm fine with them being doc(hidden). Unfortunately, we can't solely implement the trait implementing macros, and would need a macro just to spit out the Uint type def, which uses a lot of internal functions.

Maybe there's some abomination of a macro which just includes the crates own source as to output the crate itself as a module in a dependency?

Or, alternatively, Concat(Mixed) could be rewritten such that its an additional parameter such that C: Concat<A, B>. This would allow users to write struct ConcatU1024U8192; impl Concat<U1024, U8192> for ConcatU1024U8192 { type Output = U9216; }... but I do hate this idea for it mucks with the extra type parameter. I'm just grasping for alternative solutions, of which I haven't seen any discussed, which would avoid having to wait for Rust itself (even though that may be the best solution in the long run).

[andrewwhitehead]

I don't think it's going to be possible to define support for custom Uint sizes outside of the crate, at least not with support for mixing and matching of sizes. One option I was exploring is supporting the definition of custom contexts in a typenum-style crate, so that users could define all their necessary Uint sizes (and maybe inherit some defaults) within that context and specifically use a Uint<LIMBS, MyCtx> or something like that.

[tarcieri]

@andrewwhitehead it would basically need to write a complete self-contained struct providing storage which can Deref and delegate to UintRef to perform the actual operations.

I'm certainly not volunteering to write it, heh.

[tarcieri]

Alternatively, we could expose just the macros that are helpful for defining such a type, leaving the complete definition as an exercise to the user

[andrewwhitehead]

I don't think that exposing the macros would help, another crate isn't allowed to define the trait implementations which could conflict. The custom context parameter is a way to work around that, giving the target crate a type they can implement traits on.

[kayabaNerve]

I think it should be quite feasible, in a different crate, to define MyUint<N, Ctx>(Uint<N>) and go from there. That'd allow deferring the API experimentation outside of crypto-bigint upstream, but may make it take much longer to ever be upstreamed, though I'm unsure such a solution (whatever it may be) would be anyways.

FWIW, extending Uint with a Ctx generic which is by default, set to whatever is defined in crypto_bigint, but the user can define their own to provide a variety of relationships actually does seem straightforward and feasible. By default generic types, it wouldn't even be a breaking change...

[tarcieri]

Perhaps instead of a context object, Uint could be generic around its internal storage. Then BoxedUint could be a type alias for Uint.

[kayabaNerve]

An internal storage of approximately S: AsRef<[Limb]> + AsMut<[Limb]>, which is then deferred to for implementing Concat and similar, could be super interesting. That'd remove having to wrap/defer any/all of the arithmetic and allow solely focusing on how one composes array/buffers. Whether that be [Limb; N], hybrid_array::Array<Limb, U<N>>, Box<[Limb]>, or heapless...

[andrewwhitehead]

BoxedUint could become a specialized version of a type with a storage type parameter (see also #1148), but Uint could not without losing support for most of the const methods (unless const trait implementations make it into the language). It would be easier now to make it generic with more of the logic implemented on UintRef.

[tarcieri]

@andrewwhitehead you can still write the const methods today when using a concrete type for the generic parameter.

Also by the time we’re ready to make such a change, const traits may be stable.