> On Mar 4, 2024, at 5:14 PM, Ian Lance Taylor 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
>> key
On Mon, Mar 4, 2024 at 11:32 AM Mike Schinkel wrote:
>
...
> 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`, arr
> On Mar 4, 2024, at 12:18 PM, Jeremy French 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
> usefu
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
On Mon, Mar 4, 2024 at 9:40 AM Jan Mercl <0xj...@gmail.com> wrote:
>
> The static type of an interface can be verified at compile time. The
> value of a variable of an enum type (or a Pascal-like subrange) type,
> cannot be verified at compile time in the general case. You would have
> to add featu
On Mon, Mar 4, 2024 at 6:19 PM Jeremy French 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. In
> fact, it's fairly easy to see, even in this case, where the PrintMonth
> signature
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.
In fact, it's fairly easy to see, even in this case, where the PrintMonth
signature would have to return an error, when that is pretty much the o
On Monday 4 March 2024 at 15:18:05 UTC Jeremy French wrote:
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)
ISTM all that's needed is to have a way to create a named type which c
On Mon, Mar 4, 2024 at 4:19 PM Jeremy French wrote:
> It's checked at compile-time rather than run time.
That requires immutability of variables of enum type. Go does not
support immutable variables.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" gr
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
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,
Hello, gophers. Lately I've been working quite a bit with enums as I'm
moving a C program I had to Go, 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
12 matches
Mail list logo
