Option to have default data type (without wiring a constant) at the input of Select function.

[moderator1983]

I would like to have an option, where programmer can select 'Default Data-type' at 't' or 'f' input of a Select function so that, he need not connect a constant (with default value) 

[Darin.K]

Except that it helps a lot with preventing programming mistakes. That's exactly the sort of terminal that I will frequently forget to wire. I wager 90% of terminals on my subVIs are Required... and that 10% is mostly error clusters.

Catching those programming mistakes is what VI analyzer is for, what warnings should be for, and part of each developer's style.  I do not see any need for it to be included in the syntax of a language.   Unless LV is going to crash, I do not see the need to break the run arrow. 

With Objects I know when I place a constant with the default value, it is really the default value regardless of changes that I make later.  When you force the creation of the constants, they only reflect the current default value.

[Intaris]

I strongly disagree that syntax is not crucial for detectkng programming mistakes.

The idea of skipping LabVIEWs many syntax checks and offloading to vi analyzer is a truly terrible one.

[Darin.K]

What is the syntactic difference in a by-value language between an unwired input which implies a default value and the wired constant?  Not stylistic difference, but syntactic difference. 

Some primitives do change behavior based on wired inputs, not so much subVIs although you can play games with XNodes or Polymorphic VIs to do it. 

[Intaris]

It's completely OK in certain cases to leave inputs unwired.  I don't think my last comment expressed any particular opinion on that aspect of things.  My problem was simply with the statement that "catching those programming mistakes is what vi analyzer is for".

I do find, however, that it is a perfectly valid approach for any given LabVIEW code to define inputs as required and then break the VI until the problem is fixed.  This is, for me, one of the most valuable things LabVIEW has to offer, the immediate feedback whether the guidelines of the components of your software have been adhered to or not.  The definition of such rules and the strict adherance to it is a major factor in the fight against bugs.

It's up to the creator of the components (primitives, sub-VIs) to determine what is required and what not.  It is then, in my opinion, perfectly valid and indeed extremely valuable to have LabVIEW give immediate feedback on that.

As an aside: I would be ALL for a primitive which takes any wire as an input and gives a default instance of that datatype as an output.  I think this would be a better solution to your differentiation between "always default" and "current default".

[AristosQueue (NI)]

Darin : It's a timing thing. I don't want to find out about runtime bugs at the end of the day when I am running VI Analyzer (assuming I even run it during development when lots of things are half done).  I don't want to waste a day chasing down a runtime bug that my compiler should have detected and flagged as a failure.

[Darin.K]

Don't get hung-up on VI analyzer, I think warnings are a much more useful tool for this type of thing and what I would strongly argue for.  (I always show warnings and clear them ALL, after time you figure out how to avoid the nuisance warnings).  VI analyzer is what I would use to track down constants set to the default value. NI loves to tout how you are always closer to running code with LV than C++.  It should be even closer.  C++ is bound by a lexical grammar so errors can propagate simply looking for that one misplaced semi-colon or brace.  It is very hard to deal with partial code (getting better, it can often guess what you should have done these days and often offers to fix it for you).  LV quite naturally pushes some of the parsing job to the programmer, the difference between the code and the equivalent syntax tree is not that great.  Dead code is quickly and easily indentified and ignored, and unlike C++ does not propagate the error into unrelated sections of code.  If I drop an Add primitive on the BD it does not have to break anything, it can be simply and easily ignored.

Take one of my favorite examples which I hit almost every day:  Spreadsheet String to Array.  The Format String is a required input.  I can have it fully wired otherwise with my chosen default type and input string, but it insists on a Format String.  Create Constant later I now have an empty string constant and the code is happy.  What exactly does this empty string constant which is prompty ignored do for me?

As far as I am concerned, code safety and robustness comes from input validation,  requiring a wire simply shifts blame.  Code should handle 0 whether it is input by a control, by a constant, or implied by default.  If you want, make the default value out of bounds and handle that error.

[AristosQueue (NI)]

> requiring a wire simply shifts blame

You're going to have to explain that one to me. Shifts it to who?

To me, required/recommended has *nothing* to do with input validation. Of course the underlying node needs to sanitize its inputs, regardless of the required/recommended setting. This has everything to do with giving the user of the API a checklist to follow. It is exactly the same reason you would mark a dynamic dispatch VI as "Must Override" for inheritance, or leave a broken wire in a template VI.

To me, wiring the constant "empty string" says "I made a consious decision about the value that goes here and the empty string behavior is the one I want." Leaving it unwired means "I didn't even think about it." For terminals that the vast majority of the time want the same value, use Recommended. But if it is a terminal that only gets wired with its default value down around 60% of the time, it should be Required. Being required gives me, the programmer, the reminder to evaluate the terminal and pick the value that goes to it. Choosing between Required and Recommended means the API designer must think about the expected usage of the terminals, and when in doubt, the terminal should be required.

[AristosQueue (NI)]

PS: I have *many* times been asked to implement "required output error terminals". Lots of people have asked me for it over the years. It just hasn't been something I've made a priority. But there is clearly demand for making sure that the error gets handled *somehow* instead of just casually forgotten. The ability of LabVIEW to do dead code elimination is, to many folks, a bug, not a feature. Instead, it should be flagging the dead code and saying, "What did you intend to do here, because you put work into this and it doesn't do what you think it does."

[Darin.K]

If your subVI has a problem running with the default value and nothing is wired by the user then it is your fault as the author.  By making the input required, the same subVI with the same input value causes the same problem but now it is the user's fault for wiring that value.  I strive for my code to be agnostic in terms of how that value got to the input.

I program in too many languages to think in terms of default values.  I prefer to think in terms of default behaviors.  I try to have my subVIs, functions, methods, whatever, perform well with default behaviors.  I may change my mind later as to what specific value gives me the best default behavior.  If I change the default value of say the subVI control or inside a function declaration, I know that all of the code using that will update to reflect improved default behavior.  If instead I have to track down every instance and update some constant I am less happy.

Overuse of required terminals leads many users (I have seen first hand, and there is even a QD shortcut to speed the process) to simply create constants removing the very thought process you had hoped to put there.

If < 10% of terminals are required you have to think.  At roughly 50% you probably figure someone is throwing darts.  By 80% I figure it is a knee-jerk reaction and leads to constant propogation.

[AristosQueue (NI)]

> If your subVI has a problem running with the default value

> and nothing is wired by the user then it is your fault as the author.

That's not the problem. As I said... this has nothing to do with input validation. The subVI has no idea whether the value came from a wired constant or from the default value. Making the terminal required or recommended changes nothing about the underlying code. Nothing.

> I strive for my code to be agnostic in terms

> of how that value got to the input.

It always is anyway, so I'm not sure what you're striving for. Changing an input to be Required doesn't change the block diagram of the subVI. It changes the caller's diagram.