You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
given the above wit definition, wit-bindgen rust a.wit generates functions like:
pubfn set1(v:V1,){
pubfn set2(v:&V2,){
it's a bit surprising to me they are incompatible.
IMO, it's better to keep the same API for trivial changes like this.
i suspect it's simpler for users to use the generated code if you always use borrowed parameters for compound types like variant/record/etc for example.
The text was updated successfully, but these errors were encountered:
The change might be small in text, but semantically it is not trivial: the b(string) variant is of variable length, where as the a(u32) is of fixed length. This distinction is very meaningful in terms of how the bindings generator, as well as the user of the bindings, has to manage memory.
The change might be small in text, but semantically it is not trivial: the b(string) variant is of variable length, where as the a(u32) is of fixed length. This distinction is very meaningful in terms of how the bindings generator, as well as the user of the bindings, has to manage memory.
are you talking about something rust-specific?
the corresponding C binding doesn't seem to involve the incompatibility.
always use borrowed parameters for compound types like variant/record/etc
for example,
given the above wit definition,
wit-bindgen rust a.wit
generates functions like:it's a bit surprising to me they are incompatible.
IMO, it's better to keep the same API for trivial changes like this.
i suspect it's simpler for users to use the generated code if you always use borrowed parameters for compound types like variant/record/etc for example.
The text was updated successfully, but these errors were encountered: