3 ms·
Yes, those examples too assign a number to something. Enumeration is not a new concept. In fact, it's an incredibly old concept that emerged in programming lang
by randomdata 3y ago
Yes, those examples too assign a number to something. Enumeration is not a new concept. In fact, it's an incredibly old concept that emerged in programming langauges as a hack to work around our, a the time, limited understanding of type systems. A modern type system has no reason for enums at all. Of course, Go purposefully tries to be an 'old' language, hence why it copied the antiquated pattern of providing assignment of numbers as a language feature.
- pjmlp 3y agoYou mean it copied how programming used to be before 1970's. Great achievement.
- randomdata 3y agoNot really. Enums as a programming language construct are a 1970s invention. Funnily enough, Algol 68 had sum types, although controversially so due to overhead concerns. If only Go had copied the state of programming before 1970, then we wouldn't have to listen to all the nonsense about enums sucking. Of course they suck – they are, and always will be, a hack to work around a limited type system.
- pjmlp 3y agoGo does not have any kind of enumerations, what is has are constants and a gigantic hack for pseudo enumerations, they even compile with broken values! package main import "fmt" type planet int const ( unknown planet = iota // invalid mercury // Mercury 0.378,2439.7,3.3e23,57910000,88,0.0000000001,0,false venus // Venus 0.907,6051.8,4.87e24,108200000,225,92,0,false earth // Earth 1,6378.1,5.97e24,149600000,365,1,1,false mars // Mars 0.377,3389.5,6.42e23,227900000,687,0.01,2,false jupiter // Jupiter 2.36,69911,1.90e27,778600000,4333,20,4,true saturn // Saturn 0.916,58232,5.68e26,1433500000,10759,1,7,true uranus // Uranus 0.889,25362,8.68e25,2872500000,30687,1.3,13,true neptune // Neptune 1.12,24622,1.02e26,4495100000,60190,1.5,2,true ) func main() { landingOn := venus fmt.Printf("Landing on %d\n", landingOn) landingOn = 42 // What a hack! fmt.Printf("Landing on %d\n", landingOn) } https://go.dev/play/p/9AzJeHB0YbT https://go.dev/play/p/9AzJeHB0YbT
- randomdata 3y ago> they even compile with broken values! Of course. Same as C: #include <stdio.h> enum planet { unknown, mercury /* ... */ }; int main() { planet landingOn = mercury; printf("Landing on %d\n", landingOn); landingOn = planet(42); // What a hack! printf("Landing on %d\n", landingOn); } Value constraints have nothing to do with enums. Enums are exclusively about numbering – and as your code shows, the numbering works just fine. Value constraints are an independent feature. One that Go (and C) lack completely, not just in the case of enum values. You can compile with broken values throughout. Consider: type EmailAddress string var email EmailAddress = "Not an email address" // A-OK! Compare that with a language with a more advanced type system like, say, Typescript: type EmailAddress = `${string}@${string}` let email: EmailAddress = 'Not an email address' // Compiler error You can probably make a good case that Go would benefit from value constraints, among other features, but if you're going to start adding such features, why have enums at all? Again, they're a hack to work around a limited type system. If your type system isn't limited...
- pjmlp 3y agoNow do the same with 1970's Pascal enumerations.
- randomdata 3y agoPascal doesn't really have enums as a language feature, so there is no direct analog. It has enums as an implementation detail, but for all intents and purposes the language could be implemented with something other than enums. The same is not true of C or Go, which make enums a first-class citizen of the language. That is, with the caveat that Pascal does allow the union to be converted to its underlying enum representation. If we provide such conversion to get at the enum, then sure: Program Lander(output); type planet = (unknown, mercury); var landingOn: Integer; begin landingOn := Ord(mercury); writeln('Landing on ', landingOn); landingOn := 42; writeln('Landing on ', landingOn); end. But you're ultimately comparing apples and oranges.