From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
0 Kudos
JimChretz

Implicit element to array conversion

Status: Declined

Any idea that has not received any kudos within a year after posting will be automatically declined. 

Is it possible to have something like this? Even with 2D, 3D,... arrays.

 

Untitled.png

21 Comments
AristosQueue (NI)
NI Employee (retired)

The usual argument goes something like this...

 

Weak Type Advocate: "What else than an array with one element could you expect from that coercion?"

 

Strong Type Advocate: "It has nothing to do with expectation. It has everything to do with whether or not that's the intended result. You just took something that has a non-zero probability of being a miswire and allowed it to turn into a run time error."

 

Weak Type Advocate: "But any click the programmer does could be a mistake. The computer shouldn't try to second guess. If the computer can assign meaning to a click, it should accept the click. That opens up the most flexible and fastest code development without making the programmer jump through a bunch of hoops. What, are you going to put 'are you sure?' dialogs after every node that gets dropped?"

 

Strong Type Advocate: "There are clicks that are probably correct and there are clicks that probabaly incorrect. We do a service when we warn people and make them confirm that they really intended to do something that is either an unusual action OR is an action that has multiple possible intentions, instead of just picking one and going with it."

 

Weak Type Advocate: "If you want to warn people, warn people. Add a compiler warning. But don't break their code!"

 

Strong Type Advocate: "When was the last time you turned on warnings?"

 

Weak Type Advocate: "Never! The warnings list is useless in LabVIEW! There's too much noise."

 

Strong Type Advocate: "It's useless in every programming language. Unless your company treats warnings like errors and 'breaks' the compile (i.e. won't let you check in code), the warnings proliferate and any new important warnings get lost in the noise. The only useful warnings are the ones that actually break the compile."

 

At this point the two parties glare at each other across the table. Then they get hungry, and go to different restaurants. The strong type advocate gets food that is approved by the FDA and served from a kitchen that has passed health inspection. The weak type advocate grabs whatever off the sidewalk and has the ambulance and other emergency services on speed dial.

AristosQueue (NI)
NI Employee (retired)

For the record, these same two people have the same argument (dev speed vs dev correctness) about required vs recommended inputs to functions and a host of other features.

JimChretz
Active Participant

There's no way you will have a run-time error because of a one element array. Name one case, don't need to reply a 10 paragraphs post, just one convincing reason and I might buy it.

Intaris
Proven Zealot

You could have wired up the wrong wire to the wrong terminal and then later wonder why your code isn't working as expected.

 

Simple as that.  No broken wires, LabVIEW claims all is well, yet the code doesn't do what you originally wanted to do because you connected a scalar output to the array output of your function X which really should output an array.  Now your array data is in limbo and all of the code expecting a 16-element array are suddenly receiving only a 1 element array.  What?

 

Nasty debugging ensues.

 

If you want an array, wire an array.

JimChretz
Active Participant

Ok but this will happen if you connect a string to another string terminal and will result into nasty debugging too.

AristosQueue (NI)
NI Employee (retired)

> Ok but this will happen if you connect a string to another

> string terminal and will result into nasty debugging too.

 

Yes... see the discussion between Strong and Weak above. You just made the second arguement. I can step back and let you and Altenbach play this out. I was trying to save you typing by spelling out the usual exchange. 🙂

 

And regarding strings, that's why you should have different typedefs for different string uses. At least, in the opinion of the strong type advocate.

JimChretz
Active Participant

I think I got your point guys.

 

In this case that would be hard for the compiler to decide what to do by default, we need to take a decision so the whole thing doesn't make sense. Is it a N elements array compared to a 1 element array or is it compared with an array of N elements with copies of the same value? I guess there could have even more different interpretations, so I get it, can I discard my idea? 🙂

 2015-03-17 12_48_36-Untitled 1 Block Diagram on ABT.lvproj_My Computer rev. 0 _.png

AristosQueue (NI)
NI Employee (retired)

We could close it. But even with the ambiguity, there are many people who would support the idea, so I'm inclined to leave it open and let others give it kudos if they think it has value.

ToeCutter
Active Participant

You know about 'right click terminal->create constant', right?

JimChretz
Active Participant

@ToeCutter wrote:

You know about 'right click terminal->create constant', right?


I do, do you have more to say about it?