I think what Jeremy mentions in here is the key to the issue. There would
be more consensus and less interest in "fixing" enums in Go if there was a
tangible way to restrict their values to what is stated by the developer.
El lunes, 4 de marzo de 2024 a la(s) 12:18:05 p.m. UTC-3, Jeremy French
escribió:
What I find valuable is to be able to accept an enum as a parameter to a
function, and know that it will be one of several approved values (e.g.
month of the year), without having to have boiler plate to check or throw
errors if it's not one of the approved values. It's checked at
compile-time rather than run time. Whether that could be handled via
go:generate or not, I wouldn't know. I haven't used go:generate, but
frankly at first glance it seems like using a sledgehammer to crack a
walnut. Maybe if you use go:generate regularly anyway, that would make
sense. But it seems like overkill to involve go:generate just to be able
to have enums. But again, my familiarity with go:generate is that which
you get from 30 seconds of a google search.
On Sunday, March 3, 2024 at 5:32:24 PM UTC-5 Mike Schinkel wrote:
I have recently seen many are complaining about a lack of enums in Go. But
while there are many ways in which I would like to see Go improved, enums
barely even rank on my list of priorities.
The majority of my experience prior to Go was with dynamic languages that
did not have explicit enums, and in working with Go I never really felt
that enum functionality was missing.
That said, what am I missing? What it is about enums that have so many
people clamoring for them in Go? Is it having a textual representation
managed by the compiler that a go:generate cannot solve? Is it having a
syntax that allows treating them like an object with a property, e.g.
HttpStatuses.NotFound that otherwise requires too much boilerplate? Or is
it something else?
Further, what can you envision doing with a "proper" enum that you cannot
already do with a custom-typed constant?
Thank you in advance to whoever helps me understand why enums are such as
burning desire for so many developers.
-Mike
On Mar 3, 2024, at 12:25 AM, Nicolas Serna <serna.nic...@gmail.com> wrote:
Hello, gophers. Lately I've been working quite a bit with enums as I'm
moving a C program I had tGo, so I wondered if there was any progress on
enums proposals and realized that none of them get anywhere without
breaking the Go1 compatibility.
I've decided to get a bit creative and share with you the proposals I've
thought of.
The fundamental thing when we talk about the incorporation of "robust
enums" is, similarly to the case of generics, to propose a syntax extension
to the language without breaking compatibility with the previous software.
We use enumerations simply to handle states and encapsulate them under a
name. Therefore I wanted to propose the following syntax:
```proposal
const (<ENUM_TYPE>) <NAME> <TYPE> = <VALUE>
```
The idea of this syntax is that, roughly speaking, it reminds us of what we
do when we declare a method, with the only difference that in this case we
use constant values associated to some "enum type". Then, we should be able
to call our constants as follows: <ENUM_TYPE>.<CONSTANT_NAME>, the same
would be true for an already instantiated type.
```example
type Statement struct{ /* ... */ }
type StatementTyp int
const (Statement) (
Prepared StatementTyp = iota
Success
Fail
)
func main() {
stmt := Statement{}
fmt.Println(Statement.Prepared) // 0
fmt.Println(stmt.Success) // 1
}
```
Realistically speaking this doesn't solve much. It just gives us a way to
encapsulate constants in an "elegant" way and keeps the "const-iota"
syntax, but little else.
I think it is essential to have an extra way to reference these internal
values of a type so that we can work with the help of the go-typechecker.
For this I could only come up with two types of syntax, let's see:
```prop1
var bar const <ENUM_TYPE>
func foo(arg const <ENUM_TYPE>) {...}
```
```prop2
var foo <ENUM_TYPE>.const
func bar(arg <ENUM_TYPE>.const)
```
That would be all, I hope you can give some feedback and know what you
think. I read in the go2-language-template
<https://github.com/golang/proposal/blob/master/go2-language-changes.md>
that it was better to post my ideas in this group instead of making a issue.
Thanks for reading ^^
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/134fd31b-9081-4d22-b098-412244338fc5n%40googlegroups.com
<https://groups.google.com/d/msgid/golang-nuts/134fd31b-9081-4d22-b098-412244338fc5n%40googlegroups.com?utm_medium=email&utm_source=footer>
.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/a3b1cc23-29c9-43b6-9679-eac301bb5f92n%40googlegroups.com.
