-
Notifications
You must be signed in to change notification settings - Fork 1
Description
For ease of development of this library, generics quickly end-up being assumed to always be present. Also on this line, this library's functionality internally started as inside changes on the sdk, but as incompatibilities started showing up from the rest of the sdk (ie. couple hundreds of non-fixable errors, as the library functionality was just starting), this library also quick split itself from the sdk into a solo crate.
Going back to generics, when they aren't being used (including associated types), most struct definitions should be compatible (if not identical) to those created by the sdk. This is desired because it should make this library core features (generics) not break previous contracts, and that being the case, a backport to the sdk (which would be much more beneficial to the ecosystem) would tend to have much fewer impediments.
Still there would be some pain-points on compatibility, like the separation of extern "C" function generation from the trait/impl attributes, although this could be minimized with customization attributes.