Secure modules w/ the const-mutable type

This is a prososal to allow what would otherwise be assignable to a var, to const (while disallowing function calls), and to disallow module-level vars to stop it from being abused. It is part of a set of proposals for improving Golang's security model.

// These are all OK

// const mutable (slice) type (all slices are mutable)
const myArray = make([]byte, 10)

// const immutable (struct) type
const myStruct = MyStruct{...}

// const mutable (struct) type
const myStructP = &MyStruct{...}

// const immutable (interface) type w/ struct value
const myStruct MyInterface = MyStruct{...}

// const mutable (interface) type w/ pointer value
const myStructP MyInterface = &MyStruct{...}

// const immutable func type (all funcs are immutable)
const myFunc = func(){...}

Here, const doesn't mean that the value is deeply immutable. It just means you can't change the shallow value--you cannot change myStruct's fields, and you cannot change where myStructP points to, but you can change myStructP's fields. In the latter example, unlike var myStructP = ... no code is able to swap out the entire object.

There is already a distinction between typed and untyped consts. This only works for typed consts, and further introduces a distinction between const-mutable const-immutable types. While the procedural behavior of const func types are always "immutable", they may have side effects.

The right hand side expression of a const declaration may not include a function call. This limits the scope of these new const-mutable and const-immutable to those that won't cause a const initialization fiasco (see https://groups.google.com/forum/m/#!topic/golang-nuts/BnjG3N77Ico).

The type of values you can assign to a const are more expressive, so we now have no excuse to declare module-level var variables which can be (maliciously or not) modified by anyone who imports the module.

(Of course we can declare a global function func GetMyStructP() *MyStruct { ... }) that more or less does the same thing, but nobody does that because it's easier to use var, and what's the point of doing the right thing unless there's a commitment to evolve the language toward a capabilities-based system?).

Go linters can start tagging exported global vars that aren't annotated to be safe to mutate by anyone.

The proposal here is not to make module level state "immutable". Consts can still be mutable internally, but the pointers that they refer to cannot be swapped out for another pointer. I'd like for Golang to have these mutable consts (they're so convenient), and to disallow exported vars entirely.