Coercion dot - to <data type> vs type cast

[StevenD]

I found this a bit odd and hoping someone can shed some light. I have an array in my program where all the data will be U8's, but for clarity on what they mean, some of them are typedefed rings. When I build the array of native U8's and typedef rings I get a coercion dot on the native data type, even using "to unsigned byte integer". Using type cast gets rid of the coercion dot. What's even stranger to me is using the native "to <data type>" to a convert to a different type than what the typedef is set as (IE change a U16 to a U8) also gets rid of the coercion dot. Is there a reason for this behavior?

Relating to my project, I don't want to convert all the native U8's to the ring data, I want the ring to be converted to a basic U8.

Why is the top build array converting the u16 to a typedef ring?

[Kyle97330]

I'm pretty sure this is just a common property of all standard base-level LabVIEW nodes.  If a value is passed through a node with the same data type, and the incoming wire is type defined, so is the output wire.  

You can try it with non-numerics.  Type define a string and it passes the type def through a "string subset" node.  Typedef a VISA reference and it passes through a "VISA Write" node.

I'm pretty sure that since "Build array" is also a standard node, it follows these same rules, so even if you pass in one type defined input and any number of non-typed wires of the same data type, the entire array output will always be type defined.

[StevenD]

Perhaps I should have worded my question a little better. I get the build array will try to type def the same data types (kinda anyway), but I expect using a "to <data type>" to convert to the basic data type, which it does if the data type of the ring is different from the "to <data type>". What confuses me is the behavior is not consistent. Type def U16 to U16 = type def. Type def U16 to U8 = U8.

This doesn't really affect me as I already found a solution (using type cast), but was just curious as to why and if there is a good rhyme or reason to use the "to <data types>" versus type cast.

[Kyle97330]

Maybe the confusion is the fact that a "Ring" control isn't actually using a distinct data type.  It's a special control that, when on the front panel (or as a block diagram constant) will LOOK like it's using named strings, but the wire itself is just a U16 or whatever.

If you want the data type to actually contain named strings, you need to use an Enum.  I suspect that will behave like you expect the Ring to behave.

In most cases, an enum is preferable UNLESS:

• You need to add new values live during program execution, or
• The numeric values paired with the strings mean something externally and don't match an Enum type well (since enums by definition start at zero and have to include every value after that, you can't skip straight to 4000 without adding in 3999 meaningless enums)

Using a type defined "Ring" can lead to unexpected behavior.  For instance, if you change the type definition of a Ring to have a new value listed, it doesn't update existing constants with that new string/value pair.

[wiebe@CARYA · Accepted solution]

Converting the U16 type def to U16 doesn't need to do anything, so the output is still the type def.

Converting to U8 has to change the type, so the type def is removed.

This is not inconsistent, as the situation is different.

The cast from U16 is explicit, so it does remove the type def.

I'd prefer a variant to data or coerce to type (over a type cast):

The type cast is dangerous. It might fail if you change your type def to U8 or U32. The coerce and variant to data handle 'narrowing' better.

[StevenD]

Thanks. I think the "coerce to type" is the functionality I was looking for. I still think, at least in my one case, "to <data type>" should convert to the basic data type, but maybe there is a valid reason to preserve type defed data.