Why not rely more heavily on trait implementations ?

[Roms1383]

Hi everybody ! (but especially people who implemented the lower levels of FRB) :)

I have a short question, and I hope I won't take too much of your time, but something keeps popping in my mind when browsing FRB's internals. Part of the answer might be that the lib was built over time, with many different contributors, and refactoring would be a hell of a task here.

So long question short : why (de)serialization from/to FFI doesn't rely (more than it already does) on trait impls ?

I already somehow understand that, at least in its surface, FFI conversion must be "anchored" by ABI functions (extern "C" fn ...), and I already know types implement for example IntoDart from allo-isolate, which is exactly what I have in mind, but I'm just wondering why it's not more widespread for all the layers of conversion throughout FRB ?

Especially I'd reason (and correct me if I'm wrong), that this would alleviate the burden of codegen if mostly everything was trait implementation based.

[fzyzcjy]

Sure, feel free to explore using traits! As long as CI passes (i.e. no regression errors), I am looking forward to merging it. It is always desired to generate the least possible.

One reason may be that, some things are impossible to be implemented by traits. They have to be implemented by macros - but macros is indeed (almost) equivalent to code generation.

Feel free to point out the places where you think can refactor, and I may provide more details for the concrete case

[Roms1383]

Hmmm I didn't intend to refactor anything actually, I was just curious to know if it became this way over time or if it was for some underlying reason that I couldn't guess.