Merging fuels-types and fuels-core

[segfault-magnet]

Through various refactors/features fuels-core has become rather empty as of late. There are only 4 files left in it besides lib.rs:

• abi_decoder.rs
• abi_encoder.rs
• function_selector.rs
• utils.rs

As for the encoders, its UnresolvedBytes have migrated to fuels-types with the predicates pr. So a bit of it has already gone.

Function selection resolving will probably be moved to fuel-abi-types in one of the upcoming refactors @hal3e and I are doing.

Utils has one helper function for the function selector resolving.

As for encoding/decoding, being split from fuels-types causes problems for us. We can't derive TryFrom for our custom-sdk-provided-types living over in fuels-types since that would cause a circular dependency where we need try_from_bytes in the fuels-core lib.rs but fuels-core needs fuels-types.

Both fuels-core and fuels-types can be wasm compatible.

Due to all of the above, I suggest we merge the two crates into one. Either under a new name or we just call it fuels-core.

[Salka1988]

👍

[maldiss]

great idea thank you

[hal3e]

If we merge fuels-core and fuels-types would it make sense to expose types through the same path: fuels::types even though they would live somewhere in fuels-core::types. The users would not know that we moved types anywhere. I ask because we already had a feedback that types where used from various places.

[segfault-magnet]

We would need to take care not to have multiple ways of reaching the types. I.e. if we expose core as well then you could reach types via fuels::types and via fuels::core::types and we've had comments that it confused users before.

Maybe to stop exposing fuels-core as a whole? Reexport the encoding/decoding into fuels::codec (as in code-decode). Whatever else is left could probably be found a home as well.

[iqdecay]

I really like this idea of having fuels::codec and fuels::types, even if they live in the same module.