Is the explicit mutation policy too aggressive?

[gchumillas]

I wonder if the following change might mitigate a couple of problems derived from the explicit mutation policy:

struct MyStruct {
mut:
   private_var1 string
   private_var2 string
   // ...
pub mut:
   public_var1 string
   public_var2 string
   // ...
}

// not necessary to declare `s` as mutable,
// since the function doesn't change any public property
pub fn (s &MyStruct) do_something_1() {
   s.private_var1 = 'hello'
}

// not necessary to declare `s` as mutable,
// since the function doesn't change any public property
pub fn (s &MyStruct) do_something_2() {
   s.do_something_1()
}

// the language requires to mark `s` as mutable,
// since the function is changing a public property
pub fn (mut s MyStruct) do_another_thing() {
   s.public_var1 = 'bye'
}

The idea is to mark the "receiver" as mutable only when some of its public properties are mutated. This may mitigate the following problems:

1. Cascading propagation: modifying a variable mutation requires unrelated changes in different parts of the code. This is not good in a large dev environment, where commits should be self-explanatory, short, and localized.
2. Encapsulation principle: explained here.

The idea is to recognize that there's no magic formula for ensuring software security without paying a price for it. And that explicit mutability is just one more tool.

[gchumillas]

The guess is this: Sooner or later, we'll need to change some private property of MyStruct, thereby changing the signature of the public API. This would force us to plan the API in advance, making development rigid and hindering early prototyping.