Consider making all fields private with accessors

[coryan]

Our generated messages look like so:

pub struct LatLng {
    /// The latitude in degrees. It must be in the range [-90.0, +90.0].
    pub latitude: f64,

    /// The longitude in degrees. It must be in the range [-180.0, +180.0].
    pub longitude: f64,
}

impl LatLng {
    pub fn new() -> Self {
        std::default::Default::default()
    }

    /// Sets the value of [latitude][crate::model::LatLng::latitude].
    pub fn set_latitude<T: std::convert::Into<f64>>(mut self, v: T) -> Self {
        self.latitude = v.into();
        self
    }

    /// Sets the value of [longitude][crate::model::LatLng::longitude].
    pub fn set_longitude<T: std::convert::Into<f64>>(mut self, v: T) -> Self {
        self.longitude = v.into();
        self
    }
}

Maybe the latitude and longitude fields should not be public, and the generated code should be:

pub struct LatLng {
    /// The latitude in degrees. It must be in the range [-90.0, +90.0].
    latitude: f64,

    /// The longitude in degrees. It must be in the range [-180.0, +180.0].
    longitude: f64,
}

impl LatLng {
    pub fn new() -> Self {
        std::default::Default::default()
    }

    /// Sets the value of [latitude][crate::model::LatLng::latitude].
    pub fn set_latitude<T: std::convert::Into<f64>>(mut self, v: T) -> Self {
        self.latitude = v.into();
        self
    }

    /// Sets the value of [longitude][crate::model::LatLng::longitude].
    pub fn set_longitude<T: std::convert::Into<f64>>(mut self, v: T) -> Self {
        self.longitude = v.into();
        self
    }

    /// The latitude in degrees. It must be in the range [-90.0, +90.0].
    pub fn latitude(&self) -> &f64 { &self.latitude }

    /// The longitude in degrees. It must be in the range [-180.0, +180.0].
    pub fn longitude(&self) -> &f64 { &self.longitude }
}

For trivial fields like this the is not much difference and probably the change is not that useful. This may be more useful for non-trivial fields like maps, where we may want to change the representation some day, or for repeated fields or for wkt::StringValue where we may want to change the representation from String to a tuple or struct.

We could also exploit this to make hand-crafted structs in veneers behave more like the generated types, and in that case we really may have very different representations -- or representations that change more often -- of the fields.