D'oh!

[Darin.K]

Maybe there is some way for that to break your VI.  😉

[JackDunaway]

---

@Darin.K wrote:

Maybe there is some way for that to break your VI.  😉

---

That's exactly my sentiment. A function with unwired inputs and outputs should break the VI. For this and for the static/dynamic configuration tst points out, I have removed the +1 from 2009 from the idea to which Tim links since it dilutes the array indexing syntax.

Each individual "Index Array" function in the node is overloaded to accept either 0 or 1 inputs. When it accepts 0, it implicitly accepts the ++ value of the index above. When a constant is wired into an index, it statically effects the configuration of the node. A *static* configuration syntactically should be representated and contained within the node, not without.

Rather than stepping even further syntactically in the wrong direction of the lexicon defition, we should push toward breaking this node into a few separate functions (one, statically configured; the other dynamically). This view is extreme, and I don't fully support it (I think the best path forward may be to do nothing with the node). Even though overloading is convenient, the tradeoff is safety. The compiler is your friend. Embrace the broken run arrow.

[Alex.T]

Oh wow! I had no idea a configuration like that wouldn't result in a broken run arrow. I thought that if you left all of the terminals unwired, they'd default to incremental indexing, and if wired, all terminals would need some input... Seems a little crazy in terms of dataflow, but I suppose I see the advantages.

Now to lament over all of the time that could have saved me.

[JackDunaway]

---

@Alex.T wrote:

Oh wow! I had no idea a configuration like that wouldn't result in a broken run arrow....

Now to lament over all of the time that could have saved me.

---

Yep! Very handy! Watch out though, since constructs like this (and my original example!) can sometimes be a code smell, better replaced by a typed/named data structure for code readability and type safety.

My original example has since been refactored for these reasons, and is more readable and scalable (static indexing of array elements is not readily scalable!)