Allow const declarations on mutable fields

[vtjnash]

Mark some builtin types also.

Replaces #11430

Co-authored-by: Matt Bauman mbauman@gmail.com

[mbauman]

This is really cool, but removing myself from the review since I neither have the bandwidth nor expertise to meaningfully review this anymore.

[fredrikekre]

Is it more common to have a few mutable fields instead of a few const fields? Maybe it could make sense to have e.g.

struct ABC
    mutable a::Int
    b::Int
    c::Int
end

instead of having to do

mutable struct ABC
    a::Int
    const b::Int
    const c::Int
end

? Or perhaps support both...

[jtrakk]

mutable storage class specifier is a related C++ feature:

The mutable storage class specifier is used only on a class data member to make it modifiable even though the member is part of an object declared as const.

class A
{
  public:
    A() : x(4), y(5) { };
    mutable int x;
    int y;
};

int main()
{
  const A var2;
  var2.x = 345;
  // var2.y = 2345;
}

[KristofferC]

Maybe it could make sense to have e.g....

Not sure, a mutable struct with some fields marked const is still mutable, while the opposite is not true (immutable struct with mutable field is no longer immutable) so to me it makes more sense to have the annotation be a restriction.

[rfourquet]

a mutable struct with some fields marked const is still mutable, while the opposite is not true (immutable struct with mutable field is no longer immutable)

While I kinda agree (we are used to interpret struct X ... as immutable X...), a counterpoint is that struct is not spelled immutable, so the base for defining a "struct" is struct X end, and mutable can be prepended to make the whole struct mutable, i.e. all the fields, and with the proposal it could alternatively be applied to only specific fields.

[jtrakk]

In that case would these two be equivalent?

mutable struct Foo
a
b
end

mutable struct Foo
mutable a
mutable b
end

[JeffBezanson]

I agree with Kristoffer that adding a mutable field to a struct is a more dramatic change than restricting a field of a mutable struct to constant. The problem is that mutable struct has more memory layout implications than just whether you are allowed to mutate it. To make one field of a struct mutable, you have to either change the whole thing to act like a mutable struct, or allocate a Ref cell for that one field to maintain the identity of the mutable location. In contrast, if you start with a mutable struct nothing special is needed to make one field const; you can just disallow mutating it. So I think this version of the change makes more sense.