[enhancement] APFloat parametrics cleanup

[mikex-oss]

What's hard to do? (limit 100 words)

apfloat could use some (breaking) changes to improve consistency and usability of parametrics.

For example, we have:

pub fn to_uint<RESULT_SZ: u32, EXP_SZ: u32, FRACTION_SZ: u32>

which means the APFloat parametrics can be inferred with just supplying the RESULT_SZ.

But the signed version looks like:

pub fn to_int<EXP_SZ: u32, FRACTION_SZ: u32, RESULT_SZ: u32>

which means you need to specify all 3. I think this is arguably worse than both using the latter form, because then at least you are forced to specify all 3 parametrics in the same order.

We also have:

pub fn round<EXP_SZ: u32, FRACTION_SZ: u32, ROUND_STYLE: RoundStyle = {RoundStyle::TIES_TO_EVEN}>.

This one is a bit unfortunate, because we need round style to be last to take a default, but the other two parametrics can always be inferred. This restricts inference to the no parametrics specified case. To improve this one might take a larger language change.

Another example:

pub fn downcast<TO_FRACTION_SZ: u32, TO_EXP_SZ: u32, FROM_FRACTION_SZ: u32, FROM_EXP_SZ: u32>

Unlike most apfloat parametric lists (including APFloat itself, this takesFRACTION_SZ first, then EXP_SZ.

Current best alternative workaround (limit 100 words)

I usually discover these due to type inference errors and then carefully review the API.

Your view of the "best case XLS enhancement" (limit 100 words)

Parametrics should be consistent and allow automatic inference as much as possible.

[richmckeever]

I think virtually all of this type of pain with APFloat will be solved by having it use an impl, because then no function that operates on an APFloat instance will need to take its EXP_SZ/FRACTION_SZ.