removing trait impl from rust generator

[crop2000]

The current rust code generation has some limitations. The functions associated with the generated struct are wrapped into one trait. The trait defines the interface, but the interface might depend on compile options. For example -ec should be implemented for rust as well. It would break the current trait-interface. So one would need multiple traits.

But I think the code generation should not define any trait. Rather, the traits should be defined and implemented in the architecture files. I thought about architecture files primarily as files that provide usability scaffolding like here. I didn't expect single file programs like in the faust repository. I hope it is enough to provide backward compatible architecture files, like this for the faust-build crate.

The change would reduce the complexity of the code generated by rust and give more duties to the architecture files.

I am currently preparing a pr regarding this issue.

[sletz]

The general strategy we have for the C/C++ backend and architecture model is needed to put less in the code generation step, and more in the architecture files, since this is more flexible in general. The current Rust code generation has ben developed first in 2017, with little Rust experience at that time, and refine a bit from there. So yes this kind of change is welcome.

The only thing to be sure is to provide backward compatibility, and possibly have feedback from @obsoleszenz, @plule...etc. form this contributor list

[crop2000]

There is a limit to backwards compatibility. If people have a program that has a reference to the trait FaustDsp (not the dsp struct) then the trait implementation is needed and the used architecture file must to be updated. This is the case in rust-faust/rust-state crate. I will update the architecture files rust-faust and faust, for as a reference.

[crop2000]

I would favor a cleanup which reduces the generated code to the most necessary, for example it would provide const rather then functions for get_num_inputs.

but this will be definitely not backward compatible.

now i am divided between 2 thoughts.

1) because people need to add the FaustDsp trait implementation to their own architecture files anyway (if they depend on FaustDsp), we should change the generated code to be as simple as possible.

2) because people might use their own architecture files we should keep as much of the current interface in the dsp struct impl so that they only need to remove references to FaustDsp from their code which works well if they haven't depend on the trait anyway.

2 is slightly easier to reason about if one doesn't understand rust well enough.

but i think it is possible to write a trait impl that could be copied into a architecture file. then a guideline "please add this code-block to your architecture file for backwards compatibility" is maybe sufficient.