Many public facing types do not implement Debug about web-audio-api-rs

[orottier]

Thanks for the report. We should probably do this as it is also advised in the rust API guidelines https://rust-lang.github.io/api-guidelines/debuggability.html#all-public-types-implement-debug-c-debug

If you are willing to open a PR to address this that would be very welcome. You can use the #![deny(missing_debug_implementations)] lint to find all missing impls.

[CorvusPrudens]

For some types this is easy and straightforward. For others, there are many inner library types contained within. Is a simple #[derive(Debug)] appropriate for all of these, or should some of them provide an opaque debug representation?

For example, a #[derive(Debug)] on context::online::AudioContext would require an implementation for context::concrete_base::ConcreteBaseAudioContext, and potentially all of its members.

Personally, I think it would be nice, but it could end up meaning a lot of types will have Debug derived.

[orottier]

Right, good question.

I think it would be best to start small. Most of the AudioContext fields have no 'debug' value anyway and only expose internal guts that are subject to change.

Take a look at the Debug impl of RenderThread and Graph for example. I'm only exposing a few fields.

Perhaps the Debug implementation of AudioContext should only expose what we provide via public method getters (base, sink_id, latency values perhaps). ConcreteBaseAudioContext should list state, sample_rate, current_time, max_channel_count, offline. AudioParam should list all internals expect registration. Etc etc

[orottier]

Hey @CorvusPrudens, are you working on this? Otherwise I will make a start

[CorvusPrudens]

I have not! You certainly won't be stepping on my toes.