You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Has this idea, or one like it, been proposed before?
Does this affect error handling?
Is this about generics?
Is this change backward compatible? Breaking the Go 1 compatibility guarantee is a large cost and requires a large benefit
Has this idea, or one like it, been proposed before?
Yes.
I am making this proposal since the last proposal I found was from 2017, it is better that there is a more current one, on that topic they spoke very positively about it being in go, so you already know what to do.
Does this affect error handling?
No.
Is this about generics?
No.
Proposal
add a much better way of defining enums, like:
type BetterEnum enum { FIRST = "enumsaregood" SECOND = "oldenumsarebad" }
According to me and many, it is a much more readable way than doing things with constants and types.
Language Spec Changes
No response
Informal Change
No response
Is this change backward compatible?
Yes.
There is no way to remove the old way of doing it, because they would remove the constants and that makes no sense.
Orthogonality: How does this change interact or overlap with existing features?
No response
Would this change make Go easier or harder to learn, and why?
There are many ways to implement enums in Go depending on the direction the language takes.
So just as you have already labelled it v2 yourself, I wouldn't hold my breath too much until some time in the future.
But you can also take advantage of the current features and implement your enums nowadays if you find iotas unfit for your use case.
You can define a struct where enum cases are methods that return a comparable type.
E.g.
typecountrystruct{string}
typeCountrystruct{}
func(cCountry) Australia() country {...}
func(cCountry) Canada() country {...}
func(cCountry) China() country {...}
func(cCountry) England() country {...}
func(cCountry) France() country {...}
func(cCountry) Germany() country {...}
func(cCountry) Japan() country {...}
func(cCountry) Mexico() country {...}
func(cCountry) Morocco() country {...}
func(cCountry) Zimbabwe() country {...}
// ...
It even has the non negligible advantage that the unexported country type can itself have its own methods. For example, you could define one that returns the country's languages.
Some kind of enum hierarchy. It's at will and very type-safe.
Go Programming Experience
Intermediate
Other Languages Experience
Python
Related Idea
Has this idea, or one like it, been proposed before?
Yes.
I am making this proposal since the last proposal I found was from 2017, it is better that there is a more current one, on that topic they spoke very positively about it being in go, so you already know what to do.
Does this affect error handling?
No.
Is this about generics?
No.
Proposal
add a much better way of defining enums, like:
type BetterEnum enum { FIRST = "enumsaregood" SECOND = "oldenumsarebad" }
According to me and many, it is a much more readable way than doing things with constants and types.
Language Spec Changes
No response
Informal Change
No response
Is this change backward compatible?
Yes.
There is no way to remove the old way of doing it, because they would remove the constants and that makes no sense.
Orthogonality: How does this change interact or overlap with existing features?
No response
Would this change make Go easier or harder to learn, and why?
No response
Cost Description
No response
Changes to Go ToolChain
No response
Performance Costs
No response
Prototype
(#19814)
The text was updated successfully, but these errors were encountered: