The `Sample` and `Frame` traits would greatly benefit from the "associated consts" and "integer generics" features

[mitchmindtree]

Sample could benefit from EQUILIBRIUM and IDENTITY associated constants, allowing us to remove the methods that currently fill this role.

Frame could benefit from, NUM_CHANNELS, EQUILIBRIUM and IDENTITY associated constants, allowing us to remove the n_channels and equilibrium methods.

Frame would also massively benefit from integer generics of some sort in order to get rid of the NumChannels associated type, the related trait and the macro-generated implementations for every frame size up to 32 (an arbitrary, unnecessary limit).

It looks like associated consts at least will land soonish as the feature gate was recently removed. I'm not sure what the current state of integer generics is.

cc @andrewcsmith I'm leaning towards making this a 1.0 blocker as it will cause quite a significant impact on the API. Otherwise I guess we could aim to stabilise earlier and then release a 2.0 in the future when these features arrive. Looking into the progress on integer generics will probably help us to make a decision!

[andrewcsmith]

Agreed. One possibility though would be to keep the API the same through 1.0 and then add the associated consts as soon as that feature lands, deprecating the n_channels etc. methods until the inevitable 2.0. Could be a thing where we see where the features stand once all the milestones are taken care of and slip it in at the end if it's good to go. These both seem like pretty quick and uncontroversial changes.

[milkey-mouse]

I just stumbled upon this library and saw this line in the docs, specifically for the Sample and Frame traits:

NOTE: This will likely be changed to an "associated const" if the feature lands.

I'm not sure if this is still applicable, but associated constants are stable now. Maybe it's just me (not an expert Rust programmer), but I don't see how 23b7c6a has anything to do with, let alone closes, this issue...

[mitchmindtree]

Thanks for the heads up! I must have accidentally referenced this pr number instead of another in that commit. I'll re-open this.

I have had some other thoughts regarding this issue lately - I think it would be useful to be able to distinguish between fixed size frame lengths and dynamically sized frame lengths (e.g. Signals whose number of channels change over the course of a program).

[linclelinkpart5]

According to rust-lang/rust#79135, it looks like a minimum subset of const generics will land in Rust 1.51, which should be releasing towards the end of March! If that's the case, I'd love to help out and "const generic"-ify the internals of dasp.

[mitchmindtree]

If that's the case, I'd love to help out and "const generic"-ify the internals of dasp.

@linclelinkpart5 please feel free! Exciting times in Rust land to have const generics nearing stabilisation :) I look forward to seeing how much we can improve upon dasp's API as a result.