Rust bindings

[ben.boeckel (Ben Boeckel (Kitware))]

@jonaspleyer

There are some ugly workarounds but the idiomatic way of solving this is to provide methods with separate signatures.

Another possibility is to build up an enum with the parameters:

#[non_exhaustive]
pub enum SetNameArgs<'a> {
    Pattern1(i32, i32, &'a str),
    Pattern2(int, &'a str),
    Pattern3(&'a str),
}

This can the be matched on to call the appropriate C++ method. It may also be possible to even write impl From for (T, U) tuples to allow just “double wrapping” the args with obj.set_name((port, name)).

Note that just naming based on index is subject to ordering changes in the source becoming Rust binding API breaks. Of course, adding a new overload is also a way to break the Rust bindings as well as it would then morph into this pattern and the “just pass args” usage would fail.

@jonaspleyer

Another way would be to determine the “meaning” of the parameters and thus define new methods with different names. We would still need to make sure that they do not collide with already present ones. For example:

This does seem to be far more robust to C++ API changes and Rust API effects (though renaming parameters is still a risk). Perhaps a VTK wrap attribute could be used to “name” the overload? Diagnostics could be generated if an overload is found without a custom name (and its generation suppressed until it gets a name).