Leave the For-Loop as it is

[Intaris]

Lots of ideas for different enhancements to the old trust For-Loop.

I propose leaving everything the way it is.

This is needed as a counter-weight to the multitude of "enhanced" for-loop suggestions out there.

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Smart-Iterators-with-Loops/idi-p/967321

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/quot-Start-Step-Stop-quot-structure-on-For-loops/idi-p...

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/for-loop-increment/idi-p/1097818

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Reverse-Iteration-Terminal-in-For-Loop/idi-p/1174449

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Real-For-Loop/idi-p/1211713

Spoiler

Some of the proposed versions I like but it feels like no matter which version would be implemented, 80% will be disappointed.

Spoiler

There are also some times I just think we're getting lazy as programmers

Spoiler

or Maybe Altenbach's drive for efficiency has affected us all!

Spoiler

I wonder how deep the rabbit hole goes?

Shane.

[Darren]

I'm kudoing this because it reminds me of a time several years ago in LabVIEW R&D when some colleagues approached me with an idea they had for giving the For Loop two frames...one for regular execution, and one for zero-iteration execution.  Uh, NO.

-D

[AristosQueue (NI)]

That's the same attitude that killed the "Stop" terminal on For Loops for many years. That feature turned out to have an implementation that most of us like and many of us use. I think the same is possible here, it just requires a careful sifting of the posts and some serious planning/user feedback before implenting anything.

I'm in no hurry to implement the For Loop changes, but I think the idea has enough merit to get implemented a few years from now.

[Darren]

---

@Aristos Queue wrote:

That's the same attitude that killed the "Stop" terminal on For Loops for many years.

---

No, a stop terminal on a For Loop is a great addition to the language.  A For Loop with two frames would be a terrible addition to the language.

Interesting trivia:  The same guy who implemented For Loop with Break is also the guy who proposed the multi-frame For Loop. You win some, you lose some.

-D

[Darin.K]

If it were possible to Kudo replies not only would I Kudo AQ's I would probably create a few new profiles just to do it a few more times.

Something is added to the For Loop with each version, and there are some things I would probably use before Chunk size.  I think NI will have to ask for forgiveness and not permission in this case.  Just keep the changes minimal, fully backwards-compatible, and invisible to those who don't care...

[Dragis]

as the originator of one of the ideas listed above, i agree with this idea in the spirit that we should ensure the for loop retains the ease of use it currently provides. i don't believe any of the ideas mentioned would require a change in the default for loop you get when dropping it from the palette, they simply extend the possible configurations the for loop naturally provides. in many cases, the new additions can greatly reduce the amount of code necessary to implement the desired behavior making the code easier to understand and more maintainable.

[Intaris]

There are certainly some approaches I think are do-able but opinions differ greatly as to the best implementation.....