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]

So we agree it changes nothing, so then my question remains what does it add that is so valuable that it must break my VI?  Take the spreadsheet string to array function.  Why must it break my code until I create an empty string constant for the format?  Or Bundle.  Why shouldn't it break my code until I wire a type input?  And this post, why must my VI be broken if an input of Select is unwired but already typed? Warnings, sure but why break things?

[Intaris]

A discussion on whether a specific input for a specific function should be required or recommended can be held somewhere else.

The fact that there ARE required inputs and they break the code is a different matter.

[AristosQueue (NI)]

> So we agree it changes nothing, so then my question

> remains what does it add that is so valuable that it

> must break my VI?

No. We do not agree.

It DOES NOT change the SUBVI's diagram.

It DOES change the CALLER diagram.

The fact that it changes nothing about the subVI's diagram is why your comments about input validation are irrelevant.

On the caller diagram, the error list is a critical checklist to aid in successfully using the API. And required inputs are a critical part of that checklist.

[Darin.K]

I am ready to agree to disagree.  I still see no SYNTACTIC difference in a subVI if a value of '0' comes from a wired input of 0 or the default value.  (I will go so far as to suggest that the few functions which in fact change their behavior based on an input being wired or not have been known to confuse some very knowledgable and experienced LV users). It is not the wire, it is the value on the wire in a ByVal world. "Robustness through inconvenience" is akin to "security through obscurity" to me.  See this picture:

The format string is required so the code on the left is broken.  Yet with a bogus or empty string it works fine. And screwing up the delimiter gets me way more often than the format string .  My opinion is simply that a required input breaking my code should be very important, this seems not to be the case here and many, many other cases over which I have no control (built-in functions).  I can wrap API VIs if I feel so inclined, I can not wrap Select and maintain the nice polymorphic features.

> On the caller diagram, the error list warning list is a critical checklist to aid in successfully using the API. And required inputs are should be a critical part of that checklist.

That I can completely and wholeheartedly agree with.  In a perfect world I would allow required to break a VI if used very sparingly, another class which throw warnings  which try to stop pilot error, and others which are ignored.  Breaking a VI is too big of a pain IMO given the large number of times it is used, and even where it is not used in the few cases I think it should be (ie. Bundle).  My point with input validation is simple:  a value important enough to actually break someone's code until wired should have the potential to do real damage (crash, hang, etc.).  If it really is that important it should be validated and not simply rely on the end user who is likely to simply wire the default value.

Again to relate to this idea:  I do not want a glyph at all.  But it does seem strange that leaving an input like that unwired would break a VI.  And I would rather there be some type of discussion of the bigger picture than have 500 discussions about which inputs should be required and which not.

And I am not being completely contrarian or argumentative (at least not on purpose).  I can easily see how required inputs make you feel better about your code, but I have a hard time seeing how it actually makes your code better in a concrete, quantifiable way.

[Intaris]

@Darin.

Bigger picture.

Reference inputs.

If the inputs are not wired and not set to be required required it will hurt you many times over.