Create an "Optional" input type wrapper in the style of C++17's std::optional

[cbutcher]

Currently, we can make inputs to subVIs optional (or indeed recommended) and not wire them - in this case, the default value for the input terminal is used. By default, this is the default value for the type, but it can be easily changed to another value (at least for terminals you can easily set).

Since there is no "optional" type, this leads to code potentially like

If -1 is always an invalid value here, this might not be so terrible. The issue becomes more pervasive with, for example, empty strings (or string constants) when an empty string or that constant might conceivably be a valid value.

Class objects could be an additional problem, especially if a hierarchy is considered, because you might want to wire an uninitialized child object to an Init Object method, and it would fail an equality check vs the terminal type. You might then mistakenly conclude that it was already partially/fully initialized, and carry out the incorrect processing (in this exact case, probably dynamic dispatch followed by an equality check against the specific child, then calls to a static dispatch "Init Object_internal.vi" in the parent might work).

We can work around this if needed by using a boolean clustered with the value, and then checking the boolean, but this makes wiring the subVI and creating its inputs more frustrating.

I would like to see an optional terminal type that could be checked using a primitive to indicate if it was wired by the caller or not.

(Apologies for the ugly icon, and probably dubious naming)

For the draft of the proposing paper in C++ for the std::​optional type, see http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3672.html

[wiebe@CARYA]

Duplicate: https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Wired-property-node-on-controls-and-indicators/idi-p/..., which was also a duplicate:

 https://forums.ni.com/t5/LabVIEW-Idea-Exchange/New-property-of-Method-to-indicate-if-an-input-of-a-...

The last link gives a reason why this is a definite "no".

[Darren]

 Duplicate of https://forums.ni.com/t5/LabVIEW-Idea-Exchange/New-property-of-Method-to-indicate-if-an-input-of-a-s...

[drjdpowell]

 Question: could this be done in the context of a VIM Malleable VI?   The reasons given in the other linked ideas apply only to non-inlined VIs, where the "is connected" question can vary with call site.  This idea would be quite useful for VIMs.

[AristosQueue (NI)]

> could this be done in the context of a VIM Malleable VI? 

That is a question I have actively explored. It gets really tricky to find any sort of decent syntax. I've played around with some variations, but nothing satisfactory. It somehow involves putting a control on the panel that is a cluster of the real terminal type and a Boolean, showing only the real type in the caller node, and providing the Boolean as a constant on the implementation block diagram. It gets weird, and I haven't heard a lot of call for this feature. I wanted to have this sort of thing when I first started writing in G, and I've raised the idea several times over the years, and I generally get users telling me, "Oh, yeah, I kind of wanted that one time, but I worked around it. Not a priority." So unless I found a slam-dunk, "Yeah, that works elegantly," it's not getting a lot of mental bandwidth from me.

[drjdpowell]

The primitive shown in the idea isn't elegant, but it is simple and functional. 

[AristosQueue (NI)]

Powell: That node as drawn is meaningless. Unless that FPTerminal is outputting something other than an integer, there's no data downstream to operate on, even as a primitive. Which puts us right back to discussing how to make the FPTerm output something other than an integer. And if it can output something other than an integer (i.e. a cluster of integer and boolean), then there's probably no need for the special primitive.

[drjdpowell]

I'm thinking of the node as a marker for the compiler when it does the inlining: replace with a False constant if the attached input is not connected, else replace with True.  It would never actually exist as such in the compiled code. This seems consistent with how other aspects VIM inputs work.

[AristosQueue (NI)]

I can see how that could work. It's still really weird from a "read this diagram and understand what it does" point of view. And the node would have to be restricted to be immediately downstream from an FPTerminal to have any meaning, which would be a pretty unique requirement.

[AristosQueue (NI)]

It would almost make as much sense to just say, "If there's a Boolean constant on the block diagram whose label is IsWired_<<label of control or indicator>> then on instantiation of the VIM, set the value of that constant based on the wiring in the caller."

[wiebe@CARYA]

If there was an "any type" type, the vim could check the type of the control with existing (an planned) mechanisms. To see if a control is wired, the type could be checked. This is already sort of possible, when you check if the input is an variant. But that won't work if variants are supported...

It won't work for outputs though...

A property node would make sense to me. You can create already create them for all controls and indicators. However, AFAIK they're not supported in vim.... Not sure if it's possible to allow only one property node in vim, and only inside vim. Also the CP terminals probably stop existing when the vim is instantiated. But that's all technical. From a user point of view, a property node seem to make sense.