Skip to content
This repository has been archived by the owner on Sep 20, 2022. It is now read-only.

support for immutable values #5

Open
campoy opened this issue Jun 12, 2018 · 9 comments
Open

support for immutable values #5

campoy opened this issue Jun 12, 2018 · 9 comments
Labels
enhancement New feature or request

Comments

@campoy
Copy link

campoy commented Jun 12, 2018

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!

@ondrajz
Copy link

ondrajz commented Jun 12, 2018

Could you give some concrete example for this?

@blak3mill3r
Copy link

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

@albrow albrow added the enhancement New feature or request label Jun 13, 2018
@andradei
Copy link

andradei commented Jun 14, 2018

@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".

@bruth
Copy link

bruth commented Jun 15, 2018

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

@andradei
Copy link

andradei commented Jun 15, 2018

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.

@albrow
Copy link
Owner

albrow commented Jun 15, 2018

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).

@campoy
Copy link
Author

campoy commented Jun 19, 2018

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

@albrow
Copy link
Owner

albrow commented Jun 30, 2018

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

@campoy
Copy link
Author

campoy commented Jul 2, 2018

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

6 participants