When a For Loop is Dropped Around a Node, Use Shift Registers Instead of Auto-Indexed Tunnels for Matching Scalar Inputs/Outputs

[jgcode]

I think it would be nice if LabVIEW was smart enough to know that when I drop a For Loop around scalar inputs it doesn't auto-index output tunnels - but rather uses Shift Registers - for matching inputs and outputs.

The common use case for this is with the Error input/output - it annoys me how it becomes an Array output.

As it is already wired, inline and not broken, dropping a For Loop around it should not break my code! 

Reference or Class inputs are other use case too - I want to pass the same thing around not create an Array. 

Shift registers are better than non-auto-indexed tunnels (other option) as they protect the inputs on zero iterations.

This would remove one step required for most use cases, speeding up my development experience.

[RTSLVU]

Defaulting to shift register does not make sense to me. In your example these tunnels do not need to be shift registers at all.

[crossrulz]

RTSLVU, you obviously haven't tried to see what happens to a reference that you are passing with tunnels in a FOR loop that is ran 0 times.  Hint: Your reference is lost, never to be seen again.  References HAVE to be in shift registers just for this exact reason, to preserve the reference.

And error handling also says that you should have the error cluster in a shift register to make sure you don't lose a warning or error.

[AristosQueue (NI)]

Crossrulz -- I suspect that RTSLVU is hanging on the point that in the actual pictures in the original idea, the N terminal is wired with a non-zero constant. So he/she is right -- in these particular examples you do not need shift registers.

RTSLVU -- the point of the request is to be better code if the loop has a non-constant number of iterations. If it isn't constant, it might iterate zero times. Happens frequently with autoindexing input tunnels if the array is ever an empty array. Doing the conversion to shift registers on all For Loops is good general practice because code changes and what is constant today might become a parameter tomorrow.

[Darren]

Implemented in LabVIEW 2014