Hacker News Reader

Comment by perbu | Hacker News Reader

I'm wondering if it be better if an iota would assign random, unique numbers at compile time, just to make it clear that these are not entirely safe identifiers inbetween compilations.

View on HN

If only there were a way in computer science to guarantee you couldn’t misuse a value. Then you wouldn’t need to rely on using UB to scare people into not making a mistake. (A dig at Go not your comment :-)

Yeah, if only there were decades of programming language design research and field testing since C for Go to draw on...

Iota does have other uses where this behavior wouldn't work, such as for defining bitmasks:

    const (
       Flag1 = 1 << iota
       Flag2 = 1 << iota
       Flag3 = 1 << iota
       ...
    )

The magic const shorthands even let you omit the explicit definitions for everything after Flag1, but I think it's easier to get the idea when all the definitions are explicit.

Or, you know, it could learn a thing or two from C# enums (which are not even that good):

    [Flags]
    public enum Options
    {
        Default = 0,
        Option1 = 1, // can also be defined as 1 << 1
        Option2 = 2, // can also be defined as 1 << 2
        Option3 = 4 // can also be defined as 1 << 3
    }

The above is a choice, and an enum can be defined normally if it's not a bitmask. .ToString() would even format it correctly if multiple flags are toggled, it can be easily parsed with Enum.Parse<MyEnum>(text) and more. And hell, this is just tolerable implementation. It makes a lot of sense given historical context of C enums, which it's a direct improvement over, but not a step away in what is now considered to be the right direction represented by Rust enums instead.

(Luckily, unlike Go, C# allows to trivially define Result<T, E> class/struct and a method on it in the form of Map(ok => .., err => ...))

I don't think my comment ought to be the trigger for a generic rant against Go enums (or lack thereof). I was just pointing out a motivation for iota to increment in sequence from zero (rather than assigning a random unique value, as OP suggested).

You are right. Please don't take my criticism of a bad language to be a criticism of a perfectly reasonable comment :)

C# enums are strictly worse: they’re C enums, meaning they’re no safer than integers, but they don’t tell you about that.

Go at least does not pretend it has anything like enums or sum types, and that is to its credit. You create a Go integer type, it’s flagrantly shit, but it’s not subtle about it.

C# enums explicitly tell you that and it is well documented. You have easy Enum.IsDefined(enumValue) as well as Enum.GetName(enumValue) which work exactly as advertised. Switches on enum values will tell you to handle the default case too.

They are not ideal by modern standards when you look at Rust. But to state that they are worse than Go's is a new and I can't find a way in which this kind of statement would defensible.

Reply on news.ycombinator.com