Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proposal: spec: support read-only and practical immutable values in Go #32245

Open
zigo101 opened this issue May 25, 2019 · 17 comments
Open

proposal: spec: support read-only and practical immutable values in Go #32245

zigo101 opened this issue May 25, 2019 · 17 comments
Labels
LanguageChange Suggested changes to the Go language LanguageChangeReview Discussed by language change review committee Proposal
Milestone

Comments

@zigo101
Copy link

zigo101 commented May 25, 2019

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.

@gopherbot gopherbot added this to the Proposal milestone May 25, 2019
@ianlancetaylor ianlancetaylor changed the title proposal: support read-only and practical immutable values in Go proposal: Go 2: support read-only and practical immutable values in Go May 28, 2019
@ianlancetaylor ianlancetaylor added v2 An incompatible library change LanguageChange Suggested changes to the Go language labels May 28, 2019
@ianlancetaylor
Copy link
Contributor

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 fmt.Print wouldn't work without changing much of the calling code. We are extremely unlikely to adopt a proposal that requires changing code that calls fmt.Print.

@zigo101
Copy link
Author

zigo101 commented May 28, 2019

@ianlancetaylor
I added a function call example.

About the changes to fmt.Print, if we use the first solution, we can declare fmt.Print as

func Print(...interface{}::q)

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.

@ianlancetaylor
Copy link
Contributor

If I have a :rr value can I call Double?

@zigo101
Copy link
Author

zigo101 commented May 30, 2019

No rules allow this.

Only writer or writable values can be assigned to writer values/parameters.

@zigo101
Copy link
Author

zigo101 commented May 30, 2019

Except the unsafe way.

@petar-dambovaliev
Copy link
Contributor

Changes of this magnitude would only be accepted if they are absolutely crucial to the users.
I see this as a lot of work for little to no benefits.
It will essentially make it into a completely different language and opens the door to Go going the C++ route.

@zigo101
Copy link
Author

zigo101 commented May 31, 2019

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.

... for little to no benefits.

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.

@agnivade
Copy link
Contributor

agnivade commented Jun 1, 2019

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.

@zigo101
Copy link
Author

zigo101 commented Jun 1, 2019

... starting a thread with your existing ideas on golang-dev/slack/reddit and get feedback

I have tried most of them. Please read the old threads of this proposal for details.
And I found this issue tracker is the only workable feedback media.
If you have found another workable media, please let me know.

If you dont intend your proposal to be accepted in its current form, then it is simply going to be closed.

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.

  • clarify that channel types with no-references element types are also no-references types
  • providing a way (by setting the cap of immutable byte slices as -1) to represent immutable byte slices
  • introduce value role concept
  • provide a parameterized role concepts so that we can avoid function declaration splitting without using generics.
  • distinguish reader values and read-only values
  • use :role postfix to save some keywords (though I agree the current syntax is not perfect)

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.

@networkimprov
Copy link

I believe it's true that the issue tracker is by far the most active forum for discussion of Go development.

@agnivade
Copy link
Contributor

agnivade commented Jun 1, 2019

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.

@zigo101
Copy link
Author

zigo101 commented Jun 1, 2019

... I just thought it might have a better chance in golang-dev

It has been already there for several months. And the the feedback effect there is not as good as here.

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

I still disagree with this.

and they just lie gathering dust.

I really hope this issue will gathering less dust.

Just ignore this issue if you don't like it. Peace.

@petar-dambovaliev
Copy link
Contributor

I am not saying you don't make good points.
However, i think the language is fine as it is and the less changes, the better.
Piece.

@zigo101
Copy link
Author

zigo101 commented Jun 6, 2019

I think your last comment is ok. No problems with it.
My above comments didn't react to your comment.

@ianlancetaylor
Copy link
Contributor

As this proposal is intended more as description than to be adopted as is, marking as Proposal-Hold.

@scorsi
Copy link

scorsi commented Jul 2, 2020

I pretty like the idea of read-only variable but I dislike the proposed syntax, it's complicated.
Moreover, Go already has a const keyword, I think it could be extended to more than string, int and other basic types (see #37303).
But afterall, personally, I never (really) need a read-only/const value, var is enough, if someone modify a variable of a lib he shouldn't and make his program crash, it's the fault of the user, not the lib or the language (or maybe the lib maintainer should not expose critical variables).

@zigo101
Copy link
Author

zigo101 commented Jul 3, 2020

C pointer is enough too. ;D

The problem of exported variables is that it give users the impression that they may be modified. This is bad. Exported variables should not be modified after all the init functions in containing packages are called, either in outside packages or in the respective containing packages. Any of such modifications are bad practice, no exceptions. I really hope Go spec can specify this, so that all exported values (including vars, consts, declared funcs) are immutable values (for exported vars, after their respective package init phase).

Preventing some values which should not be modified being modified is not the only benefit of immutable values. There are also many other benefits.

I admit the cost would not be low to support immutable values fully. But maybe it is feasible to supported final declared values. (Maybe, like the above described, we can keep using var instead of const to declared exported immutable values.)

@ianlancetaylor ianlancetaylor changed the title proposal: Go 2: support read-only and practical immutable values in Go proposal: spec: support read-only and practical immutable values in Go Aug 6, 2024
@ianlancetaylor ianlancetaylor removed the v2 An incompatible library change label Aug 6, 2024
@ianlancetaylor ianlancetaylor added LanguageChangeReview Discussed by language change review committee and removed Proposal-Hold labels Aug 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
LanguageChange Suggested changes to the Go language LanguageChangeReview Discussed by language change review committee Proposal
Projects
None yet
Development

No branches or pull requests

7 participants