That's not possible, because changing the index or name can change the datatype.
With constants it could work, but it would require a notion of static expressions, which LabVIEW doesn't have. Without that notion, the constants might as well be controls, and there would be no way to determine the output type at compile time.
I would let it NI R&D team to look into this idea and decide on the implementation part. If we have this feature, it gives us a great flexibility in logic writing using Clusters.
Thank you for pointing it out! it gives a strong feeling that implementation of this cluster indexing is very much possible and we can add more and more cluster indexing related functions(search element, short element by name, Reverse element order etc) in LabVIEW.
>I would let it NI R&D team to look into this idea and decide on the implementation part. If we have this feature, it gives us a great flexibility in logic writing using Clusters.
They will say the output will need to be a variant. Like the OpenG VI.
Variants will be slow and would very often need to be casted back to the datatype.
Everything that can be done with clusters, you can make it yourself with variants or .vims. Your idea can be DIY-ed (quite easily), if you can live with a variant output. For everything else, we need constant (not static) expressions... That would indeed need the the R&D team, and the topic is much bigger that this idea.
My Idea is not to do with Variant. We all know its achievable with Variant but it has its own low sides, The proposed Idea is to be apply some innovation on this part and improve this. Because this would be a major add on.
The index can change at run time, the type can't. Unless it's a variant.
As mentioned, constant expressions would allow this for when constants are wired (and would break if controls where wired). That would be much more then a major innovation... If that was implemented properly, you'd get this idea for free.
