[Quest] Enum Default Value

[gregsn]

Let's look at an example enum:

FileAccess doesn't have an entry with value 0 Read = 1 Write = 2 ReadWrite = 3

---

Let's have a look at how other .Net languages treat the issue:

If you would declare a value type in C# like this:

struct foo
{
  public FileAcess fa;
}

var f = default(foo) would set the enum inside that struct to 0, a value that doesn't correspond to any enum entry. So in C#, we obviously have the idea of uninitialized and potentially invalid data.

But of course, if I only want to set a value, I only get confronted with valid options.

---

For now, we in VL don't compile to struct (we only have immutable and mutable reference types). We just consume structs. So we don't run into this issue too often.

For defaults we have a mechanism: We can adjust defaults on pin definitions. And we have a way of adjusting the default of a type:

For any IO-box, pin, or field: When there is no user-specified value in that data hub, the default specified over this mechanism shall be taken.

Is this sufficient?

Or do we need yet another mechanism that frees the user from specifying the default for enums like this? Note: this issue comes up since the UI currently takes another approach than the compiler, which leads to wrong tooltips on enums that don't have an entry 0 and don't come with a CreateDefault

[gregsn]

3 ways how to define the fallback default...

• 0
• first entry
• smallest number

[sebllll]

We can rule out the first option, since a 0 is not always available as you showed with FileAccess.

I'd go for smallest number then, which also is the first entry in almost any case, I guess.

And you still can override it via CreateDefault if the implicit default is not a good choice.

[gregsn]

I wouldn't rule it out, since we're talking about the case where the default hasn't been set. Why would we add yet another mechanism when we already have one that just needs to be used?

[gregsn]

And what would be all the pros and cons of first entry and smallest number?

[sebllll]

Ok, let's have a look on those two examples which i feel make up the corner case:

private enum EnumOne : int
{
    None = 0,
    foo = 1,
    bar = 2,
    foobar = 3,
    anotherfoo = 8,
    anotherbar = 16,
    anotherfoobar = 24
}

private enum EnumTwo : int
{
    foo = 1,
    bar = 2,
    foobar = 3,
    anotherfoo = 8,
    anotherbar = 16,
    anotherfoobar = 24,
    None = 0
}

When using firstEntry, the fallback default would be:

• none for EnumOne
• foo for EnumTwo

When using smallestNumber, both would default to none which feels right.

I can only see a Con here for the firstEntry option.

---

Of course, one can construct smth. like this:

private enum weird : int
{
    none = 1
    foo = 0,
    bar = 2,
    foobar = 3,
    anotherfoo = 8,
    anotherbar = 16,
    anotherfoobar = 24
}

Which would default to none (firstEntry) or foo (smallestNumber). But I'd argue in this case, the developer had reasons for this ordering and maybe foo is the most common usecase for this enum.

---

I wouldn't rule it out, since we're talking about the case where the default hasn't been set. Why would we add yet another mechanism when we already have one that just needs to be used?

with rule out, i meant that a fallback default to value 0 might not be a good choice, because there's no guarantee that there is a entry 0 as seen in the FileAccess one.

---

The most important point imho is, that it's a consistent choice that one can read up in the documentation.

[gregsn]

I wouldn't rule it out since we're talking about the case where the default hasn't been set.
Why would we add yet another mechanism when we already have one that just needs to be used?

with rule out, I meant that a fallback default to value 0 might not be a good choice, because there's no guarantee that there is an entry 0 as seen in the FileAccess one.

I know! I just wanted to point out that there is a way to fix such enums (imported or not): define the default manually via CreateDefault. (I btw did that for FileAccess for 2020.1.5 as a hot-fix for this particular enum.)

That's all I wanted to point out. And because there is a way to "fix" those, I think the default fallback mechanism is a wanna-have, not a must-have.

But I am of course with you that a fallback mechanism would be nice as it would free the user from defining the default manually.

Hm. We could maybe rephrase the issue a tiny bit, which is maybe only relevant for implementation(?) Or would that help for documentation as well:

If a CreateDefault definition is missing on a type, the system provides a CreateDefault definition for you. Here are the rules for different types:

• imported reference type (Class/Record) -> null
• patched type (Class/Record) -> the system builds a CreateDefault which sets all fields to their default (defined via CreateDefault), Create isn't called
• imported/patched enum -> the system builds a CreateDefault which sets the entry with the smallest number as the default ...

by defining it this way we didn't define yet another fallback system. It is one default-providing system, that just switches to auto-CreateDefault-definitions when necessary.