My take is that it looks like a normal tunnel so it should also behave like a normal tunnel.
Regarding the "Array vs Scalar" issue, I think it makes sense to link it to the tunnel it is a condition for. It is completely valid to have a conditional "Last Value" tunnel as well as a conditionsl "Indexing" tunnel. Int he first case the output of the condition tunnel should be scalar, in the second it should be an array. Easy peasy.
It doesn't look like a normal tunnel to me. I see no compulsion to follow that logic. It's a modifier to a tunnel. And if it is going to have an output, it needs its own settings for how to handle the data. It is completely valid to have a conditional "Last Value"... but it would also be completely valid to say "I only need the last value, but I need to know the pattern of rejections that happened along the way", perhaps to know how many values were dropped in the interim.
Wire it to a separate tunnel to define its output behavior. I definitely don't think this has any business being its own output directly.
Well I knew this was coming. The tunnel DOES look like a normal tunnel, the differences are minute. The right-side border of the tunnel looks exactly like any other and gives no visual clue whatsoever that it is not usable as such. How many times have ideas on this forum been argued against (from NI) because proposed visual changes are too slight to be able to clearly convey a difference in behaviour. This is an example of the latter. Claiming that the conditional tunnel does not look like a normal tunnel is a bit weak giving the amount of times the exact opposite has been argued.
Some pictures offered until now are clearly showing that the upper tunnel is wired but consider the following picture.
One could argue that the combined tunnel PLUS modifier looks different (but again the differences to stacked outputs is not huge at first glance) but then it begs the question: given the absence of a wire coming from this tunnel, where is the visual indication that it's the top part which needs to be connected apart from "Everyone knows that"? Sure we learn it relatively quickly but the lack of visual indicationt hat things are this way makes it an additional "quirk" that everyone working with LabVIEW needs to learn. It also creates a bit of a conflict with the "?" selector of a case structure which looks VERY similar to the conditional tunnel shown here (although not pixel-for-pixel identical) and funnily enough this DOES allow wiring through.
Is this a huge thing? No certainly not. If this is implemented, I do NOT want it being touted as a great new change to LabVIEW 2018..... Having said that either changing the looks of the terminal or making it accessible as proposed in this thread would be a non-zero size step to making the LV experience more consistent.
> One could argue that the combined tunnel PLUS modifier looks different (but again the differences to
> stacked outputs is not huge at first glance)
*That* is exactly my argument. That is a single tunnel, double the height of most tunnels. To argue they are separate would deny the basic point that the bottom terminal exists only to augment the one on top.
> but then it begs the question: given the absence of a wire coming from this tunnel, where is the
> visual indication that it's the top part which needs to be connected apart from "Everyone knows that"?
You have a tunnel and then you turn on a mode to augment it and an extension appears... the extension doesn't change anything about the original tunnel terminals. The visual indication that it's the top that needs to be wired is the fact that that is the part that looks like a standard tunnel.
I really don't see anything confusing with the current set up. But I do see several confusing things with trying to treat the bottom terminal as its own tunnel... something which, to my mind, would need all the same options as the top tunnel in terms of concatenation, conditioning, etc.
> would be a non-zero size step to making the LV experience more consistent.
I don't find the arguments you've put forth persuasive. I find it more confusing to conflate the behavior of a parameter with the behavior of the tunnel overall.
the basic point that the bottom terminal exists only to augment the one on top
And *this" is exactly my point: to someone without a lot of LV experience (the majority of paying customers apparently), I don't think this would be clear at all at first glance. But whatever. Over and out.
I agree with Intaris on the possibility of a confusion. The thread I refered to above stemmed from my confusion regarding the nature of the conditional terminal. And I am neither a directly paying customer (academia) nor a complete newbie.
Back when this feature was in beta, I suggested that the terminal not take up the whole width of the structure wall, so that it's clearer it's not a tunnel. Here's one of the options from back then:
We'll see how the kudos develop on this. I'm not denying the confusion of X and Intaris, I just think that giving an output terminal increases the confusion rather than decreasing it.
tst: I like the suggestion, but visually there wasn't room for the ? at that point, and the ? was considered key to identifying that terminal's role on the diagram. Still, if there's confusion here, perhaps that's worth revisiting.
I can't agree with making the conditional terminal pass-through as illustrated. All it could tell you is whether the last value was added to the array or not. I've never found it confusing either, however if there was to be a visual change, there is (just) room to show the ? but reduce the width to not span the whole loop border:
