Make Queues use the value of the data type input as default output value in error conditions

[asbo]

When a Preview or Dequeue has an incoming error, it return the default value of the data type. However, I think it could be useful for the Obtain Queue node to store the value of the data type that was passed in so that Preview/Dequeue can return that value on error. This shouldn't be a big complication to implement, and worst case it adds a memory overhead of sizeof(type).

Unless developers wired in a populated instance of a datatype, this shouldn't break previous code which depends on the default value of the data type in error circumstances.

[AristosQueue (NI)]

> Unless developers wired in a populated instance of a datatype, this

> shouldn't break previous code which depends on the default value

> of the data type in error circumstances.

It's fairly common to wire the Obtain and the first Enqueue with the same value when doing any sort of nested data structure iteration. We'd have to account for this and mutate source diagrams to create a new input for the Obtain node.

As an alternative, we could add another terminal to the Dequeue and Preview nodes for specifying the default value. What are your thoughts on that approach vis-a-vis the one you suggested?

[asbo]

> We'd have to account for this and mutate source diagrams to create a new input for the Obtain node.

I'm not quite sure what you mean by this and what its actual consequences are - can you elaborate?

The idea was spurred by this thread on LAVA. To be entirely honest, I don't have a use case for it at the moment, but I could see non-scalar data types (or maybe even scalar types) providing useful information in an error condition if they were allowed to dictate what value would be returned in that situation. There is, of course, the argument that data types could be designed such that the default value does have significance, but I see it as somewhat akin to setting the default values in a typedef or for the private data of a class.

So summarily, I see it more of a why-not type suggestion because intuitively I thought it should be that way; I can't give a concrete justification of why I have that assumption, though. To stop dancing around your direct question, adding that terminal Preview/Dequeue seems like it only be a halfway solution to my theoretical problem.

[AristosQueue (NI)]

> I'm not quite sure what you mean by this and what its actual consequences are - can you elaborate?

If version X is the version where we added this feature, then if a VI saved in version X-1 was loaded into version X, we would find all calls to Obtain Queue that were wired with a non-default-default constant OR a control, delete the input wire, create a new constant of the type that was the default-default value and wire that to the type terminal. That way all old VIs continue to behave exactly as they did in version X-1.

[asbo]

Well, I'm glad you guys do your due-diligence - I had an over-simplified view of how this might change things under the hood. Thanks for the clarification.

[drval]

It still sounds like a good idea to me with perhaps a wrapper included in new updates to anticipate the legacy code issue, a la what was done when the legacy serial i/o VIs were replaced by subVI enclosed calls to VISA.

[Darren]

Any idea that has received less than 5 kudos within 5 years after posting will be automatically declined.