[Feature Request]Introduce Visibility to Struct about move

[wrwg]

I wonder what we think how important this feature is. I would like to have it in the language (also in the context of our discussion of structs allowed as transaction parameters), but I'm not very much missing that I cannot create structs and access fields without wrapper functions outside of the declaring module. So I'm lukewarm about the relevance, specifically as we concluded to deal with transaction structs on adapter side.

The background why am I asking this is that this not trivial to implement with the way file format is defined today. A StructDefinition is local to the module where a struct is defined, and the existing opcodes for making a struct and borrowing fields are tailored to the expectation that the struct is local to a module. (I happen to remember that it was not trivial to implement the Move Prover on top of file format -- specifications have access to private structs and fields -- we needed to create move-model to deal with this).

One can always work around the current restrictions by introducing public constructor and accessor functions. Maybe instead of supporting public fields, we should derive those functions automatically i.e. have a #[derive(..)] attribute?

@sblackshear @tnowacki

[tnowacki]

• I think that we should definitely have public/private structs. Particularly given how much type-driven programming we have in Move
• I'm agree with Wolfgang in that I'm not sure how important public/private field access is in the short term
• Long term I think it might be something we add, the biggest reason is for borrows.
  • Imagine you want to do something like the following: let f = &mut s.f; let g = &mut s.g; foo(f, g)
  • This is not possible with public borrow_mut functions, as the borrow checker has no way of knowing that the function only borrows a specific field (this is lacking even in Rust FWIW, though I do think we might be able to do better if we wanted to)
• We might also want to do it for public/private constructors in the same way that Rust supports them
  • But we could also make this a source only feature, and there are several ways I could see exposing that
  • I would also be fine adding fake public fields as a source only feature, and just not allowing &mut field borrows right away due to the limitation described above