trixy/trixy-types/Cargo.toml

[package]
name = "trixy-types"
version = "0.1.0"
edition = "2021"

[dependencies]
convert_case = "0.6.0"
libc = "0.2.151"
log = "0.4.20"
proc-macro2 = "1.0.70"
quote = "1.0.33"
syn = { version = "2.0.41", features = ["extra-traits", "full", "parsing"] }
thiserror = "1.0.51"
trixy-types-derive = {path = "./trixy-types-derive"}
chore(treewide): Move the trixy subcrates under one trixy crate 2023-12-26 11:14:08 +00:00			`[package]`
			`name = "trixy-types"`
			`version = "0.1.0"`
			`edition = "2021"`
chore: Initial commit This not the "real" first commit, the others are in the trinitrix/core repository, made before the split-up took place 2023-12-23 15:07:17 +00:00
chore(treewide): Move the trixy subcrates under one trixy crate 2023-12-26 11:14:08 +00:00			`[dependencies]`
			`convert_case = "0.6.0"`
feat(treewide): Add broken Vec<E>, Result<T,E> and Option<T> types to c api These are implemented right now by simply casting the generic arguments to void pointers and providing a `type_id` field in every struct denoting the original type. This implementation, whilst being extremely unwieldy to work with on the c side, also fails in a lot of fundamental ways: 1. The `type_id` enum can never really support user defined types because we would already need it to provide the c to rust value conversion. 2. Even without custom user types the type conversion is extremely hard to correctly implement in a somewhat performant way: A vector passed from c code to rust would need to completely reallocated one element at a time. And this only works if the c side has correctly cast the void pointer to the vectors data before accessing it, as any other way would have lead to possible unaligned data (which the rust side had to account for). 3. The c api is just simply bad in this state: You have to always look at the Trixy file to even be able to deal with the data the api returns (that is: There is no mention of a results generics in the c header). Additionally the question arises if these types should even be leaked into the c code because than c just becomes a worse version of rust, which undermines the whole reason of providing a c api in the first place. One way to fix all these issues would be to change the way generics are handled by using unions instead of the void pointer and trying to avoid leaking these rust types in c as far as possible. This approach would require a lot less binding code (both on the c and rust side), but also would make the rust based c-header-gen-code harder, as it would then be required to turn a `Vec<String>` to a `char *` (and obviously a whole wrapper struct with size and string length), whilst turning a `Vec<char>` to a `char` differentiating it from a `string_t`. 2023-12-28 09:28:58 +00:00			`libc = "0.2.151"`
chore(treewide): Move the trixy subcrates under one trixy crate 2023-12-26 11:14:08 +00:00			`log = "0.4.20"`
			`proc-macro2 = "1.0.70"`
			`quote = "1.0.33"`
			`syn = { version = "2.0.41", features = ["extra-traits", "full", "parsing"] }`
			`thiserror = "1.0.51"`
feat(treewide): Finalize basic c API See the example under `./example/main/` for more details. 2024-02-19 14:50:30 +00:00			`trixy-types-derive = {path = "./trixy-types-derive"}`