rust: trivial changes to wit definition alters the API of the generated code in an incompatible way

[yamt]

for example,

package foo:bar;

interface hoge {
    variant v1 {
        a(u32),
    }
    set1: func(v: v1);
    get1: func() -> v1;

    variant v2 {
        a(u32),
        b(string),
    }
    set2: func(v: v2);
    get2: func() -> v2;
}

world useless {
    import hoge;
}

given the above wit definition, wit-bindgen rust a.wit generates functions like:

pub fn set1(v: V1,){

pub fn 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.

[pchickey]

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.

[yamt]

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

doesn't this work?