There are only two ways to tell somebody thanks: Kudos and Marked Solutions Unofficial Forum Rules and Guidelines "Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
" ... feedback nodes ... they already have an enable terminal ... "
This is not the same if N=0. Then the output is always 0, while the shift register implementation would return the value of the initialised shift register.
I've missed this option a few times... FB nodes seem like a solution, but they are just not the same.
@abostait97: There is no such feature in LabVIEW. This is the idea exchange, where ideas are proposed. This one has never been selected to be implemented.
When this idea was first posted, I thought, ok, it's a minor thing, we could do that. But today, I re-read it and realized the idea has a pretty steep downside. It may look elegant, but it would force a copy of the shift register value on every iteration of the loop (since we wouldn't know whether we needed to retain the original value or not until the end of the loop). This has the same downsides as using the Select primitive instead of the Case Structure: with the Select node, you modify value on one parallel branch, don't modify on the other branch, then choose one at the Select node; with the Case Structure, you decide whether to modify or not, then make the modifications. The compiler can avoid a data copy in the Case Structure that it cannot avoid (generally) in the Select.
This would behave like the Select node. I don't think we want to be encouraging people to use a paradigm that can accidentally impact performance so badly. Yes, we have other features (the Select node and the Feedback Node) that can cause that excess data copying, but I wouldn't want to make it *more* common.
National Instruments will not be implementing this idea. See the idea discussion thread for more information.