Update the Select node to support 'reverse' Type Propagation

[skaley]

When I connect something to the output of a Select node, I would like the input types to be updated to the connected output type.

For example, if I connect an enum to the output of my select node - if I "create constants" on the inputs, it should create the same enum type instead of a double. Similarly, when I connect a string to the output, I would expect the inputs to be strings as well.

If there is a conflict with the compiler, perhaps it could use whatever was connected first (input or output).

[crossrulz]

In cases of contradictions, the upstream (inputs) should take precedence.  And before anybody says that this is not done anywhere else in LabVIEW, they need to look at the Variant To Data node.

[Darren]

I didn't realize until reading this idea how often I connect the output of a Select and wish it back-propagated the type to the inputs so I could create constants. Kudos.

[wiebe@CARYA]

Here's the image, for those too lazy to download it:

This would make a nice little timesaver!

[AristosQueue (NI)]

I would just amend this to "fully support back propagation for all polymorphic terminals in the absence of a forward propagation asserting type". There's a few other nodes that would benefit from this. R&D has done work prototyping this, but it always takes a backseat to other work. I'll add my kudos.

[crossrulz]

AQ, would your proposition include VIMs?

[wiebe@CARYA]

>AQ, would your proposition include VIMs?

A type specialization structure on a back propagation .vim output would be really funky. And useful, for string to x conversion and the like.

[AristosQueue (NI)]

If I could make it work, yes, but it is very hard to see how to make it work. When a specific node wants to back propagate, it knows its own rules for "if output terminal is wired to X then input terminals need to be Y." For example, if Build Array is going to back propagate an array of ints, it knows its inputs must be ints. The computation is more like a lookup table than a complex function. But with a malleable VI node, somehow I'd need to compute the inverse of the entire malleable diagram, through shift registers, case structure merges, nested VIMs, etc. There's no shortcut. So I doubt it would be possible. But if it somehow fell out of other work, I'd definitely like to have it.

[wiebe@CARYA]

It could be easier when the .vim's output is connected to a back propagating node. For instance scan from string (, or another .vim \w back propagation).

Supporting this might be an easier start (no pressure, just sharing thoughts)...

If not, I see how it would be difficult. Perhaps a new node or structure would be required. And lots of work of course.

[Manzolli]

I always wanted this, but thought that it will be too complex to the compiler to handle it. Nice hear from NI that can be done. Great idea!