functional variable initialisation proposal

[beob]

[Intaris]

IIRC, you can replace it with a feedback node and utilise the initialisation methods of that instead. Functionally identical.

[NickNZ]

While feedback nodes solve this issue, I dislike them unless the backwards wire of the feedback node is a very short loop, else I prefer a while loop with uninitialized shift registers. 

Please consider a while loop instead of a for loop since its a more common design pattern in a FGV than possibly the example above with for loops. 

[AristosQueue (NI)]

I see no reason why we couldn't implement this, but it seems to me to have multiple downsides. Most of those downsides are shared with the Feedback Node today. I would hesitate about proliferating them.

My concern with this notation is non-trivial initialization code. For example, read a value from a config file and use that as the initial value.

In your example, you initialize with a simple constant. Great. But if you initialize with a computed value, that computation code runs every time (being upstream of the loop/feedback) (to read the config file, for example) and on the first call it sets the value of the register but on all future calls the value gets thrown away. In other words, you waste a bunch of time recomputing every time. You *still* need to put the First Call prim down with a Case Structure to avoid that overhead (opening and reading the file on every iteration).

Moreover, a large percent of the time that you need custom initialization, you also have some condition for re-initialization, i.e., when your program, without restarting, resets to its initial state. That situation still requires the case structure. With the notation shown here, reset has to be done by inserting the reset code somewhere along the feedback, pretty much negating the value of the notation.

To me, it's a fine solution for very simple cases, but it is easy to write non-performant code without realizing it and it is limited in the cases that it can solve.