fo icon indicating copy to clipboard operation
fo copied to clipboard

support for immutable values

Open campoy opened this issue 6 years ago • 9 comments

Hey there,

So I'm actually quite interested on this project, but the first thing I expected to find in a functional version of Go was some form of immutability.

Have you considered adding such a feature? I'd be curious on how it would match the rest of the language!

campoy avatar Jun 12 '18 17:06 campoy

Could you give some concrete example for this?

ondrajz avatar Jun 12 '18 18:06 ondrajz

This project doesn't seem to be focused on data structures...

You could try https://github.com/tobgu/peds to get immutability a la carte

blak3mill3r avatar Jun 12 '18 18:06 blak3mill3r

@TrueFurby I think @campoy is talking about a something like let for immutable bindings and var for mutable ones (which Go already has). Something like this:

type MyType struct {
    X int
    Y string
}

let m = MyType{X: 1, Y: "Immutable"}

// You can't then, modify the internals of a composite structure.
m.X = 2
m.Y = "Can't mutate me"

// You also can't change the binding to something else.
m = MyType{X: 2, Y: "Can't rebind variable m either"}

Please correct me if I'm wrong, but that's what I understood from "some form of immutability".

andradei avatar Jun 14 '18 16:06 andradei

I think @campoy may be referring to persistent data structures?

bruth avatar Jun 15 '18 10:06 bruth

Oh, I see. Thanks for pointing it out! That would be a huge change right (even compared to adding generics)? Go isn't even partially persistent.

andradei avatar Jun 15 '18 18:06 andradei

I recognize that immutability is a core part of functional programming. However, I'm not sure how we could enforce this at the compiler level, especially given the existence of the reflect package in Go.

I think immutability may be something best left to libraries to implement. For example, if you are writing a list package, it is easy to make list.List externally immutable by only exposing exported methods that always return a copy of the list. This even works against reflect (since reflect can only mutate exported values).

albrow avatar Jun 15 '18 20:06 albrow

Yeah, but I would expect at least slices to be immutable?

campoy avatar Jun 19 '18 01:06 campoy

@campoy I'm not sure what you are proposing exactly. Can you elaborate? How would this work with the existing slice type in Go?

albrow avatar Jun 30 '18 23:06 albrow

I'm not sure how it would be implemented. Everything I'm saying is that it seems important to have a concept of immutability in a purely functional language. Otherwise the referential transparency will be broken which leads to issues with concurrency.

This is more of a question / proposal rather than a "you need to fix this" issue.

campoy avatar Jul 02 '18 13:07 campoy