Assert structural type match with growable y inputs behaving as an or logic gate

[jacemdom]

Would allow to reduce the complexity and number of frames needed in a type specialization structure when the action is basically the same.

For example in the attached vim, the number [2] frame could be used for all number types and thus eliminate all the following frames.

[AristosQueue (NI)]

We are these days trying to build the minimum number of nodes into LabVIEW to achieve any given functionality and leaving any build-up functionality to G code. Now that we have VIMs, that's a more viable strategy than it was two releases ago. Unless the time savings is enormous and covers a wide range of users, we're preferring bulkier G code over bulkier C++ code. The latter is easier for everyone to debug, modify, etc. And if it only needs to be written once and the results are just as performant at run time then a bit of bulk seems a fair price to pay.

You'll see that in particular in the LV 2019 release (assuming all goes as planned) -- there's a wide range of obvious operations for a particular new feature that won't be in the palettes at first because we're mostly only releasing the foundation nodes and will release higher-level functionality later, building out of G -- though I try to never promise future functionality. 😉

[jacemdom]

Thanks for the insight into NI's strategy.

When is the 2019 beta starting?

[Darren]

See idea discussion thread for a viable workaround for the original use case.