Not going to happen on mere tunnels. There's not enough visual space to show on the diagram what the operation is, and without that, we just increase the complexity and decrease readability of block diagrams, leading to an increase in programming errors.
BUT... if you want to propose syntax changes for the borders of loop structures, then this could be considered. I'd love to see some other versions develop. You just have to suggest how you would like such interactions to work.
I know this is a trivial application, but what about this as a visual design option for the tunnels. I was thinking they could be a submenu of last value and still be able to have a conditional modifier.
Your middle two are nearly indistinguishable for me. I know most of the symbols that we could put in the middle of those boxes become unreadable for a wide range of users (as we learned when we decided to do the concatenating tunnels). We are running up against the limits of human vision in that syntax.
My thought was more like you say "any VI that has a single input can be 'mounted' on the border of a loop and will be invoked for every iteration." You then need some way to call that same VI special for first iteration and last iteration. Something like that.
> My thought was more like you say "any VI that has a single input can be 'mounted' on the border of a loop and will be invoked for every iteration."
Actually there could be two inputs if we allow conditional mode. 😉 (For example exclude some from the MAX or from the SUM (if a value is NaN or Inf or similar)).
However, I do think that all these special tunnels are easily implemented using real code, so no vote from me at this time.
Any idea that has received less than 4 kudos within 4 years after posting will be automatically declined.