Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
proposal: Go 2: support read-only and practical immutable values in Go #32245
The full proposal is here: https://github.com/go101/immutable-value-proposal/blob/master/README-v9.a.md
Please note, the new syntax in this proposal is not the core of the proposal. I know it is not perfect, welcome to suggest any alternative better ones for the syntax.
This propsoal is not intended to be accepted, at least soon. It is more a documentation to show the problems and possible solutions in supporting immutable and read-only values in Go.
changed the title
proposal: support read-only and practical immutable values in Go
May 28, 2019
It would help to have more examples of function calls. What do the function argument types have to look like to accept the various type modifiers?
You suggest that the obvious change to
About the changes to
which means values of any roles can be passed to this function (but they all will be treated as reader argument values), to avoid changing user code.
Implicit role conversions are disallowed is to avoid this problem.
Generally, such declaration form should only be used for functions in standard package. For the case of changing a reader parameter to a writer role in a new module version should not happen in standard package.
Such cases are also expected to be rare for 3rd party modules, but once they happen, and module users are not aware of the changes, there will be some consequences which need a long time to notice.
Changes of this magnitude would only be accepted if they are absolutely crucial to the users.
I would repeat it again: This proposal is not intended to be accepted, at least soon. It is more a documentation to show the problems and possible solutions in supporting immutable and read-only values in Go.
I hope this proposal can help others get a good understanding on the problems and current solutions in supporting read-only values in Go, so that they can get inspired and improve the current read-only value proposals or make better read-only value proposals.
This is a surprised conclusion. So do you think all the rationales mentioned here are non-sense?
It is welcomed if you can make this proposal simpler. It is also welcomed if you can make your own simpler one.
If you dont intend your proposal to be accepted in its current form, then it is simply going to be closed.
If you are looking to showcase the current limitations of immutable types and spark a discussion, which leads towards a final, fully speced out proposal, then I would recommend starting a thread with your existing ideas on golang-dev/slack/reddit and get feedback. And then file a proper proposal when its ready.
I have tried most of them. Please read the old threads of this proposal for details.
Why? I have seen many rough open proposals submitted years ago. Are all of them intended to be accepted?
I'm sorry if this proposal makes you feel offended. If it is true, please just ignore it. Thanks.
If you think there are nothing new ideas in this proposal, you can close it. This is the only reason I think which is a good reason to close a proposal issue.
If you find there are any flaws in this proposal, please post them here and let's discuss about them.
From my view, I have worked on this proposal for about half year, and I think there are several new ideas I haven't found in other proposals.
Sorry for writing so many, I just hope Go community can be more friendly and constructive. I welcome any constructive criticisms with concrete points, such as reporting flaws, etc. In fact, without several history constructive criticisms of this proposal, the proposal will be much rougher than the current one.
I apologize if I came off as rude. My point was if you yourself do not intend the proposal to be accepted, then perhaps this is not the right place to discuss it. Some proposals do become a discussion, and at the same time, some do not, and they just lie gathering dust. And this is rather an open-ended discussion. I just thought it might have a better chance in golang-dev. But it seems you have already tried other mediums.
Hope that clarifies my comment earlier.
It has been already there for several months. And the the feedback effect there is not as good as here.
I still disagree with this.
I really hope this issue will gathering less dust.
Just ignore this issue if you don't like it. Peace.