Zero Iteration For Loop Behavior Change Suggestion

[Ryan_Wright_]

The current behavior of a zero iteration For Loop with data that passes through it is shown below. The value passed out of the loop is the default value for the data type rather than the data itself.

If you do not want this behavior, you must replace the border tunnels with a shift register. My suggestion is to change the current behavior and instead pass through the actual data rather than the default data type value if a For Loop iterates zero times. Many LabVIEW developers, especially newer ones, are not even aware of the current behavior, which can lead to bugs in software using For Loops.

Obviously the picture above is a contrived example, but this situation can occur quite easily if an auto-indexed array is wired to the left border of the For Loop and the array is empty at run-time with other pieces of data being passed through the loop.

[wiebe@CARYA]

Only in this trivial example there is a logical relationship to the input and the output.

In a complex VI with n inputs, anything in between and m outputs, it will be impossible, for a human but esp. for the compiler, to link the m outputs to the n inputs.

[wiebe@CARYA]

There actually are situations where there is linkage between input and output, even at 0 iterations:

I haven't explored how that holds up in more complex situations. I expect the compile gives up pretty easily.

[JÞB]

No please!  The current behavior is EXTREMELY well documented in the help and training material.   Replacing the tunnel with a SR or FBN is not more trouble than fixing all of the existing code this feature would break!

[_carl]

I'd downvote this if possible. Just imagine the decades of code that would break once this was released!

[Darren]

This would be a language-breaking change. The bar for making these kinds of changes to LabVIEW is incredibly high, and would require an immense benefit relative to the work required to mutate existing code to account for the new behavior. The existing behavior is documented, and tools exist for detecting the problematic pattern described in the original post, including the 'Unused Code' test in the VI Analyzer Toolkit.

[JÞB]

Just to prove that my memory is still working.   

You can always use LabVIEW 6.0 or earlier to get undefined data from 0 iteration For Loops

See screenshot from the 7.1 release notes pg 7

 

Still, we should not be going backwards. 

[wiebe@CARYA]

>You can always use LabVIEW 6.0 or earlier to get undefined data from 0 iteration For Loops

Tried to kudo that post, but kudo-ing comments is (still, undesirable,) disabled once the idea is declined.

[JÞB]

---

@Ryan_Wright_ wrote:

The current behavior of a zero iteration For Loop with data that passes through it is shown below. The value passed out of the loop is the default value for the data type rather than the data itself.

If you do not want this behavior, you must replace the border tunnels with a shift register. My suggestion is to change the current behavior and instead pass through the actual data rather than the default data type value if a For Loop iterates zero times. Many LabVIEW developers, especially newer ones, are not even aware of the current behavior, which can lead to bugs in software using For Loops.

Obviously the picture above is a contrived example, but this situation can occur quite easily if an auto-indexed array is wired to the left border of the For Loop and the array is empty at run-time with other pieces of data being passed through the loop.

---

If I recall correctly,   those undefined data caused all sorts of trouble until the compiler learned to actually use a defined value!  I didn't use 5.1 through 6.0 long enough to write every possible bug.