> On Mar 4, 2024, at 5:14 PM, Ian Lance Taylor <i...@golang.org> wrote:
>> 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}`?
>
> I think this is https://go.dev/issue/6386.
Thank you Ian for acknowledging, and for the link, and yes that issue does
cover it.
However, that issue is a general superset whereas I was proposed a very
constraint language enhancement.
In that issue it seems the pushback was:
1. It is unclear where to draw the line on what to allow because of all the
ramifications, and
2. "Nice to have" is not sufficient reason to add a feature to the language.
> The simple version only works if the variable
> can be declared and initialized in the same statement. That isn't
> alway feasible, which is why init functions exist. It absolutely
> prohibits circular data structures, which could be limiting.
Those are definitely challenging concerns when considering the larger ask for
the proposal in issue 6386.
However, to address the enum use-case maybe a much smaller subset proposal
could suffice, one that can be declared and initialized in the same statement
and that has no need for circular data structures.
One that could also address both of those aforementioned criticisms:
1. The subset to include would only be those things that would be needed to
address the enum use-case, which I think would be fixed-sized arrays and
structs (and not maps nor slices I previously pondered.)
Those should be able to contain only other constants, which I think would
include contained fixed-sized arrays and structs, but nothing with a pointer
and attempting to take the address of any of those constants should throw a
compiler error.
2. This proposal would not be because it is "nice to have" but instead it would
enable a developer to create function whose parameters could only be satisfied
by one of the values of a type used for enums as specified by the developer.
IOW, it solves a legitimate development concern and is not just a nice-to-have.
The only real downside I can see is if implementing this would someone paint
the language in a corner so that it could not be enhanced in a better way in
the future. Maybe my vision is too limited, but that doesn't seem likely with
such a small, backward compatible change that introduces nothing new other than
relaxing an existing constraint.
Certainly some people would say "Well if you are going to do that, why not do
the entirety of 6386?" And if one of my hot buttons required arbitrary types to
be assigned to a const, I might be one of those people too. But the Go team
seems to be particularly adept at saying "We are doing this because we have a
specific reason, and today, we are only doing this. Maybe we'll do more in the
future, but not today." Maybe that could allow improves enums in the next
version of Go without having to eat the elephant all at once?
Here I modified is Brian Candler's example to be what I envision could address
the enum use-case:
1. Non-pointer instances of `struct` and `[...]array` are assignable to a
`const`, and
2. Casting a literal to a `struct` `[...]array` type would instantiate the type
and assign the literal's value to the first element or property.
https://goplay.tools/snippet/xuGipbUVlKz
<https://goplay.tools/snippet/xuGipbUVlKz>
Maybe this is a sufficiently small proposal to address this valid use-case that
the Go team could get behind it?
-Mike
--
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/9434DAAB-C203-43C0-A4E3-C0B5BDA0DD77%40newclarity.net.
