To follow up, in order to get rid of public fields, we'd have to require
all field names to be module-private and have the automatic "public
accessor and mutator" syntax generate "impl" declarations next to the
class. If the field was immutable, it'd have to generate two
implementations, one for &Foo and one for &mut Foo; if the field was
mutable, it'd generate one for &Foo. Then we'd have to come up with some
way to spell "this function is a getter" and "this function is a setter".
Also keep in mind several caveats:
* The field would not actually be private to the struct; it'd be private
to the module containing the struct.
* The field wouldn't really be private, as it could still be named by
the outside world in the "Point { x: 1, y: 2 }"-style struct
construction syntax. Changing this would require making the struct
construction syntax module-private as well and forcing everyone to write
constructors for the simplest of newtyped records. Right now you have to
do this, and it's one of the major reasons why a lot of people don't use
classes.
All of this makes me think that removing public fields is not worth it.
If we need to, we can make macros that generate accessor and mutator
methods and see how that goes, for those who don't want to make their
fields public.
Honestly the issue just doesn't come up in Rust as often as it does in
Java and C#; I suspect it has to do with the fact that we program in FP
style in Rust, separating code and data, more than OO style. Of course
there are benefits to OO style in many programs -- I'm a pluralist when
it comes to programming style! -- but forbidding public fields just
feels like it mandates a particular style too heavily.
Patrick
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
