> On Mar 4, 2024, at 12:18 PM, Jeremy French <ibi...@gmail.com> wrote: > > More, to prevent PrintMonth(14) which the function would have to check for > and either return an error or panic, since there is no meaningful output. ... > I was more just answering Mike Schinkel's question about why it would be > useful.
Thank you for answering my question. I tried to come up with a solution to that problem in Go using existing features and — assuming we want our enum-like values to be immutable and we don't want write a large amount of boilerplate — I was not successful. > On Monday, March 4, 2024 at 10:47:27 AM UTC-5 Brian Candler wrote: > Does this represent the problem statement? > https://go.dev/play/p/kLME_dJE9a5 <https://go.dev/play/p/kLME_dJE9a5> I'd like to present my simple analysis of the catch-22 and see if others concur? 1. In order to get immutability without significant boilerplate, we need to use `const`. 2. We *can* define a type like `Month` as Brian Candler's example showed. 3. We also can assign values of our type to our `const` constants. 4. However, we can *only* assign literals or simple expressions to a `const`. i.e. we cannot assign `Month{1}` to a `const` if `Month` were a `struct`, `map`, `array`, or `slice`. 5. Further, funcs allow literals to be used as a type without requiring them to be cast as that type which is why `PrintMonth(14)` is both possible and problematic. 6. All values that we can validly assigned to a `const` are literal values that can also stand-in for the type when passed to a func that expects that type as a parameter. Does that summarize our quandary correctly? Did I leave anything out? Assuming I did summarized correctly then it seems that any one or more of these potentially simple language enhancements would suffice to address the stated concern? 1. Allow a `const` to somehow be defined as `strict` where `strict` is a placeholder for the concept; i.e. that `PrintMonth(14)` would not be possible but `PrintMonth(April)` would be. 2. Allow a `func` too somehow have its parameter defined as `strict`, i.e. that again, `PrintMonth(14)` would not be possible but `PrintMonth(April)` would be. 3. Allow a `var` to somehow be defined as immutable thus allowing immutable vars and types of subtypes `struct`, `map`, array, and/or slices to be used as pseudo-enums. 4. Relax the allowable values that can be assigned to a `const` to include values that can be fully determined at compile time such as `const April = [1]byte{4}` thus allowing `const` and types of subtypes `struct`, `map`, array, and/or slices to be used as pseudo-enums. Did I miss any potentials? Did I get anything wrong? -Mike P.S. Seems to me that #4 might be the simplest way forward as it would allow for creation of types that cannot be represented as their literal subtype value to pass as a parameter to a `func`, and it would not require any new keywords or concepts added to Go the language, or at least I don't think it would? Is there any reason Go could not relax the allowable values for const to be able to support constructs that can be determined at runtime such as `const April = [1]byte{4}`? As an aside, if this solution is viable then it would also be nice if the cast `Month(4)` could translate to `[1]byte{4}` when `Month` is defined as `[1]byte`, and equivalent for `struct` and slices, i.e. that `Month(4) would assign to the first element or property of the `struct`, array, or slice. It could easily be limited to those with only one element or property, though. -- 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/21C8009D-F312-45CE-99C7-2B017603F60B%40newclarity.net.
