News for hackers. Stuff that matters.
Re:Leveraging the Go Type System by marcus_holmes on Tuesday February 09, 2021 @11:43AM (#26079550)
The points about iota are interesting. I always define the first constant as "unknown" when defining a set of iota-driven constants. That way the zero value is "unknown" so if I create a new struct with no initialiser it doesn't accidentally inherit a value I didn't mean it to have, and instead gets the "unknown" value.

It also doesn't touch on the other useful "system" funcs to include on a type (Scan, Value, Marshal, etc)

Re:Leveraging the Go Type System by corylanou1 on Tuesday February 09, 2021 @11:45AM (#26079581)
Agreed. There are a couple of clever ways to handle iota, but as my next article suggests, in general, I steer away from them if you really just need constants.

I didn't go into any of the Scan/Value/Marshal etc as it was a little beyond the scope of this article. I can certainly do a follow up article on it though

Thanks for the feedback!

Re:Leveraging the Go Type System by marcus_holmes on Tuesday February 09, 2021 @02:19PM (#26081429)
Yeah I read the article about iota. It was interesting, and there's stuff there I agree with, but on the whole iota is too useful not to use (imho).
Re:Leveraging the Go Type System by jerluc on Tuesday February 09, 2021 @12:02PM (#26079813)
I feel like there are times when zero values can make things awkward (e.g. boolean flags often need to be expressed in the "negative" form because the zero value is false), but this is a great idea for iota!
Re:Leveraging the Go Type System by marcus_holmes on Tuesday February 09, 2021 @02:23PM (#26081471)
Totally agree. Time zero values are my bane. I've started using sql.NullTime for all time values regardless, just so I'm clear about what is what.

* yes I know time.IsZero() is a thing, and the semantics are similar, but I want the compiler to warn me if I'm trying to use a time without checking if it's actually initialised first.