For types that are marshaled as handles, fields on the type aren't directly accessible. If a field is public on a handle type, we could generate a property that allows code on the C# side to still access that field in order to better mirror the Rust API. This would also require that the cs_bindgen proc macro generate getter and setter methods for that field, though that should be doable.
This relates to #20, which proposes exposing user-defined getter/setter methods as properties on the C# side. Some thought needs to be given to how we can avoid conflicts between public fields and user-defined getters/setters with the same name, e.g.:
#[cs_bindgen]
pub struct HandleStruct {
// Would be exposed as a `Field` property in C#.
pub field: String,
}
#[cs_bindgen]
impl HandleStruct {
// These methods would also be exposed as a `Field` property in C#.
pub fn field(&self) -> &str { ... }
pub fn set_field(&mut self, value: String) { ... }
}
Likely this would mean still generating a property, but preferring the user-defined getter/setter over auto-generating one, along with the option of using attributes to further tweak the generated C# code.
This is currently blocked on #44, since we haven't yet figured out how to expose access levels specified in Rust to the C# code generator.
For types that are marshaled as handles, fields on the type aren't directly accessible. If a field is public on a handle type, we could generate a property that allows code on the C# side to still access that field in order to better mirror the Rust API. This would also require that the
cs_bindgen
proc macro generate getter and setter methods for that field, though that should be doable.This relates to #20, which proposes exposing user-defined getter/setter methods as properties on the C# side. Some thought needs to be given to how we can avoid conflicts between public fields and user-defined getters/setters with the same name, e.g.:
Likely this would mean still generating a property, but preferring the user-defined getter/setter over auto-generating one, along with the option of using attributes to further tweak the generated C# code.
This is currently blocked on #44, since we haven't yet figured out how to expose access levels specified in Rust to the C# code generator.