proposal: spec: enums as an extension to types
# Yet another enum proposal Related: #19814, #28438 # First of all, what is the issue with `const`? Why can't we use that instead? Well first of all, `iota` of course only works with anything that works with an untyped integer. Also, the namespace for the constants are at the package level, meaning that if your package provides multiple utilities, there is no distinction between them other than their type, which may not be immediately obvious. For instance if I had my own `mat` (material) package, I'd want to define `mat.Metal`, `mat.Plastic`, and `mat.Wood`. Then maybe classify my materials as `mat.Soft`, `mat.Neutral`, and `mat.Hard`. Currently, all of these would be in the same namespace. What would be good is to have something along the lines of `mat.Material.Metal`, `mat.Material.Plastic`, `mat.Material.Wood`, and then `mat.Hardness.Soft`, `mat.Hardness.Neutral`, and `mat.Hardness.Hard`. Another issue with using constants is that they may have a lot of runtime issues. Consider the following: ``` var ErrInvalidWeekday = errors.New("invalid weekday") type Weekday byte const ( Sunday Weekday = iota Monday Tuesday // ... ) func (f Weekday) Valid() bool { return f <= Saturday } func (d Weekday) Tomorrow() Weekday { if !d.Valid() { panic(ErrInvalidWeekday) } if d == Sunday { return Saturday } return d + 1 } ``` Not only is there a lot of boilerplate code where we _define_ the "enum", but there is also a lot of boilerplate whenever we _use_ the "enum",
Posted by deanveloper on Nov 28, 2018, 3:22 PM
Tags
Related issues
Raise real-world problems, find people facing the same issue, and discuss solutions.4,000 issues0 comments
github (EdTech)
Message limit 10000 team edition
[NEW] Data Tiering - Valkey as general data store not just in-memory data store
Info: No releases on google play for now
proposal: spec: sum types based on general interfaces
Users can't use IdPs outside of the ones enumerated by RPs
CLIP Training Code
Implement a Set primitive to complement Dictionary and Array
better documentation of reborrowing
proposal: spec: enums as an extension to types
# Yet another enum proposal Related: #19814, #28438 # First of all, what is the issue with `const`? Why can't we use that instead? Well first of all, `iota` of course only works with anything that works with an untyped integer. Also, the namespace for the constants are at the package level, meaning that if your package provides multiple utilities, there is no distinction between them other than their type, which may not be immediately obvious. For instance if I had my own `mat` (material) package, I'd want to define `mat.Metal`, `mat.Plastic`, and `mat.Wood`. Then maybe classify my materials as `mat.Soft`, `mat.Neutral`, and `mat.Hard`. Currently, all of these would be in the same namespace. What would be good is to have something along the lines of `mat.Material.Metal`, `mat.Material.Plastic`, `mat.Material.Wood`, and then `mat.Hardness.Soft`, `mat.Hardness.Neutral`, and `mat.Hardness.Hard`. Another issue with using constants is that they may have a lot of runtime issues. Consider the following: ``` var ErrInvalidWeekday = errors.New("invalid weekday") type Weekday byte const ( Sunday Weekday = iota Monday Tuesday // ... ) func (f Weekday) Valid() bool { return f <= Saturday } func (d Weekday) Tomorrow() Weekday { if !d.Valid() { panic(ErrInvalidWeekday) } if d == Sunday { return Saturday } return d + 1 } ``` Not only is there a lot of boilerplate code where we _define_ the "enum", but there is also a lot of boilerplate whenever we _use_ the "enum",
Comments (0)
No comments yet. Start the discussion.