"Enumerated Variant" Data Type (like Rust and Zig have)

[Jim_Kring]

See this github repository for a more complete proposal and an example implementation that gets us c....

Some languages like Rust and Zig have a feature called Tagged Enums (or Sum Types) that allow you to create a data type that can be one of a few different types where there is a name associated with each type. In LabVIEW, however, Enums are limited to consecutive numeric integer values -- there's no way to associate a type with each named value.

The power of combining an Enum with a data type for each value is that we could potentially use a Case Structure as a switch statement with type assertion and data conversion built in! This would allow us to create robust, type-safe code that is easier to maintain and understand.

 

See this github repository for a more complete proposal and an example implementation that gets us c....

[GregR]

From early on in LabVIEW's life we discussed creating a type safe version of C unions. We never created anything for a variety of reasons. I'd say the big one is that you can create a pretty effective approximation of this without anything new. The core functionality comes down to N setters and N getters, one of each for each option. The data can be stored as a cluster with items for each type or a cluster with a variant. Using just a cluster means the data can be accessed directly and used incorrectly. Putting that data in a class means the data can be protected and the API can guarantee the data is used correctly.

Yes, this means you must create that class and the setters/getters but that is finite overhead. If you create enough of these, it could also be automated.

The biggest thing missing is the case structure support as has been previously mentioned. Kind of feels like "extension mechanism for case selectors" should be its own idea. That could be a heuristic like the "first enum in a cluster" suggestion, but a way to provide a VI would be more flexible. This kind of mechanism could include being able to provide a different type on the output of the selector per frame.

[wiebe@CARYA]

>Yes, this means you must create that class and the setters/getters but that is finite overhead. If you create enough of these, it could also be automated.

In my experience, even the simplest getter (an unbundle) can bring performance to it's knees (in loops). Probably simply the overhead of a DD call, although it felt un-proportionally high. The only workaround I found was to buffer the type(s)...

[Intaris]

---

In my experience, even the simplest getter (an unbundle) can bring performance to it's knees (in loops). Probably simply the overhead of a DD call, although it felt un-proportionally high. The only workaround I found was to buffer the type(s)...

---

In my experience too. The inability to inline DD VIs (Because of the afore-mentioned dynamic loading of classes at run-time - this makes it impossible to define the scope of DD calls as "complete" at compile time) causes all sorts of issues.

[GregR]

Jim started this saying he was looking for an alternative to implementing this with a hierarchy of classes. My approach uses a single class with no derived classes so dynamic dispatch is not a concern and these accessors could be set to inline.

[Intaris]

Hmm, OK. In conjunction with your "extension mechanism for case selectors" I think I only now understand your previous post.

That "extension mechanism for case selectors" would allow either version to be implemented by the user. It would be a very nice addition, syntax-wise.

[Jim_Kring]

GregR, I’m liking the Case Select extension mechanism idea. I could Invision an interface (.lvclass) in the labview/resource folder that defines the extension interface.

I could then inherit from that Case Select interface in my EnumeratedVariant.lvclass (in my example proof of concept).

[Intaris]

I'm going to again plead for a solution that works without classes at all.

Such a solution should of course allow the ability to do this WITH classes, but should not have classes as a requirement.

Have a dialog to allow the user to select from the wired resource which "part" (non-LVOOP) or "accessor" (LVOOP) should be used for the Identifier and we're basically all happy, no?

[GregR]

Have a dialog to allow the user to select from the wired resource which "part" (non-LVOOP) or "accessor" (LVOOP) should be used for the Identifier and we're basically all happy, no?

---

I wouldn't say so. If the user is going to have to manually select the "data" then they can manually add any accessor they want. To me the value of this is being able to define the behavior once and have it be automatically used any time that data type is wired to the selector.

The problem then becomes how to associate this information with a type. Having a class or typedef gives a natural place to store this association.

[Intaris]

OK, the dialog for the datatype instead of for the case. I'm fine with that.

Right, so a typedef would be enough?

No class needed.

Agreed.