proposal: spec: add read-only slices and maps as function arguments

[henryas]

Background

I recently stumbled upon a bug and after hours of searching, I managed to find the culprit, which is a function that accidentally modifies the slice argument passed to it. The problem is that as I took several subsets of the original slice and gave them new identities, I forgot that they were still pointing to the original slice. I don't think this is an uncommon issue, and hence the proposal below.

Proposal

I would like to suggest the idea of defining a read-only slice and map in the function arguments. For example, we can define a function as follows:

//function definition
func MyFunction(const mySlice []byte, const myMap map[string][]byte) []byte

//usage
mySlice := []byte {0x00, 0x01} //normal slice definition. There is no weird const whatsoever.
myMap := make(map[string][]byte) //normal map definition.

//you are still using slice and map as you normally would. Slice and map are still modifiable,
//but MyFunction cannot alter the original variables.
MyFunction(mySlice, myMap)

//you can still make changes here
myMap["Me"] = 0x01

or in the interface definition:

type MyInterface { MyFunction(const mySlice []byte) []byte }

Why slices and maps?

With structs, interfaces and built-in types, it is easy to tell whether you want them to be modifiable or not. With slices and maps, it is not so easy to tell. Maps are probably less prone to accidental changes, but slices are tricky, especially when they get passed around many functions.

Implementation Options

Read-only slices and maps are shallow-copied upon being passed to the function. Hence, any accidental change is local to the function. I understand that this will not prevent interior mutability, but exterior mutability is good enough. I think this implementation option is probably less intrusive and there are fewer breaking changes to existing codes (if any) - possibly none.

Alternatively, we may have a more elaborate system where the compiler will not compile if a function tries to modify a read-only slice/map. However, this leads to a very complex solution. What if a new sub-slice is taken from an existing read-only slice, should it be immutable too? Now, what if that sub-slice is passed into another function, should the compiler check whether the other function preserves the integrity of the sub-slice?

I personally tend to lean with the first option.

Syntax

In order not to add any new keyword, I am thinking of reusing const, and it is also more intuitive to those familiar with C-family programming languages. However, I am open to suggestions.

---

Let me know what you think.

Thanks

[mvdan]

This has been discussed before, and such big changes to the language won't be made in 1.x. I believe there were proposals to also make string be a constant []byte.

[dgryski]

@rsc's previous evaluation of read-only slices: https://docs.google.com/document/d/1-NzIYu0qnnsshMBpMPmuO21qd8unlimHgKjRD9qwp2A/edit

[henryas]

Russ Cox's evaluation applies to the second part of my possible implementation options. While I welcome full-blown read-only types, I do agree that it is a complex issue that must be thoroughly analyzed.

However, what I originally required is nothing revolutionary. See the first implementation option. It can be done in Go 1.x now, but it requires boilerplate for each type. See illustration. It would be nice to have a keyword to do automatic shallow-copying for slice and map for all types without the boilerplates. The objective is to protect the original variables against accidental changes. After slicing and re-slicing and several functions later, it was crazy to track all those mutated slices to find who did what that caused the bug.

[dnfield]

I think this is a great idea, but I don't like the idea of shallow copying. There's nothing stopping you from creating your own types over a slice that do this, and that way at least it's very transparent to you and consumers that they're actually getting copies of data.

I'd love to see go support read only types that are enforced at compile time. Slices in particular - simply have a compile error if someone tries to invoke code that would involve assigning to a slice that's const or read only. I understand it'd be a bit more involved than that, but it'd be very helpful.

[henryas]

Go's slices are way too powerful and flexible that people rarely have to deal with arrays directly any more. In my opinion, a slice should be a read-only view into an array. So if people want to change the content of an array, they would need to deal with the array and not its slice.

If we are going into that direction, then there is no need for new keywords to indicate immutability.

[davecheney]

Appending is a very common operation, how do you propose that append would with your read only slice proposal?

…

On 17 Jun 2017, at 21:58, henryas ***@***.***> wrote: Go's slices are way too powerful and flexible that people rarely have to deal with arrays directly any more. In my opinion, a slice should be a read-only view into an array. So if people want to change the content of an array, they would need to deal with the array and not its slice. If we are going into that direction, then there is no need for new keywords to indicate immutability. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[dnfield]

I do not agree that slices should become exclusively read only. Being able to modify slices is an attractive feature, and changing that would be a very radical breaking change.

Appending to a read only slice should throw a compiler error, like any other operation that involves assignment

[henryas]

How about this? You can still work with slices as usual. You can slice, re-slice, append, make it point to different values, etc. However, regardless what you do to the slice, it won't change the backing arrays and slices. You can think of a slice like a pointer. You can make it point to different values at any time, but in this case you can't change the value you are pointing at.

[leiser1960]

What is the goal? Better documentation, or race free code?
Your proposal goes for the first, I assume.
You give the the guarantee that your function will have no way to alter the underlaying array.
But you do not get the guarantee that your function is race free in respect of changes to this array, because other goroutines may modify the underlaying array concurrently.
Adding immutability to golang should go for both goals, i.e. full value semantics as we have it for strings. This changes assignment as well as comparison semantics. But would help significantly reasoning about non sequential program behaviour.
Adding a simple form of immutibility to the type system of go is big challenge, both for language design and implementation. But please go for it!

[dnfield]

I agree that immutability would be great, but I think that's a little different from read-only. For instance, you could make copy-on-write slices that are immutable - any reference to them points to a structure that doesn't change. That could certainly be powerful and useful, but a bit different from what I understand this proposal to be, which is a bit narrower in scope: simply to have compile time checking that a slice can't be written to if passed as readonly or created as readonly.

…

On Sat, Jun 17, 2017 at 1:25 PM, leiser1960 ***@***.***> wrote: What is the goal? Better documentation, or race free code? Your proposal goes for the first, I assume. You give the the guarantee that your function will have no way to alter the underlaying array. But you do not get the guarantee that your function is race free in respect of changes to this array, because other goroutines may modify the underlaying array concurrently. Adding immutability to golang should go for both goals, i.e. full value semantics as we have it for strings. This changes assignment as well as comparison semantics. But would help significantly reasoning about non sequential program behaviour. Adding a simple form of immutibility to the type system of go is big challenge, both for language design and implementation. But please go for it! — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#20443 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIOKxX3FGb5iAbgyXz0uLPvBJWLDlPZkks5sFAwagaJpZM4NhrYK> .