Beoran

This points to a deeper problem. Immutable scalar types do not make much sense, since scalar types are always copied. Only non scalars, i.e. arrays, slices, structs passed by pointer...

Note what I am talking about are values, not types or variables. That is actually something important to consider, the difference between those three. Integers, floats, pointers and go strings...

This doesn't do much to simplify the type system because now you need three key words in stead of two. I would say, please think about it in an engineering...

Well I would say that perhaps we don't need all this detail. Simply have const apply on the whole type and all it's indirections. I don't think immutsble by default...

Thanks for your enhusiastic reply! I think our main disagreement is centered on this point: > Bugs caused by mutable shared state may be rare, but they're of the most...

> This is a controversial statement. I think we both had quite different experiences. Which is exactly why I am asking for concrete evidence. I would love to be proven...

I need this similarly but with 2bpp palettes, for graphics for a game for an 1980ies game console.

@ianlancetaylor The core problem with porting Go to other platforms, and making out of tree ports now is that the go runtime, standard library and compiler are not very modular...

@ianlancetaylor Well I wanted to bring it up but I agree it is a separate issue in the end.

@aclements That's a great first step, and i am all in favor of that. @paulzhol It sounds like maintaining a secondary port is pretty labor intensive and /or inconvenient. Maybe...