Vizzy list BUG

I have created a suggestion: Vizzy: pass-by-reference for lists.

@analyzer1 I'm sorry the change has affected your working code. You have a good point. It would be fair to make a suggestion post to add support for pass-by-reference for lists.

Unfortunately, that might break some existing programs, but ultimately it needs to be done.

@AndrewGarrison I guess this change broke my aircraft landing program. I have helper custom instructions for computing a running average:

• computeAverage(list) It does not modify list. It returns an average of list elements.
• addToQueue(list, elem, maxLength) It adds elem to the end of list and optionally removes some elements from the front such that the length does not exceed maxLength.

So now the addToQueue does not work, since it modifies a copy of the original list. I coded my program in 0.9.404.0 and it worked as expected: the original list was modified.

Of course I could just remove the method and inline this code. But there are some useful cases for PID controller programming: if you have many PIDs in your program, you may want to store their state in a list - I actually considered this since my program uses more than one PID. Then you could write a single custom instruction that is passed a list (one list instance per PID) and it updates values kept in it. In this case you might keep previous error and computed error integral value in the list. Alternatively, Vizzy could be improved to have not only lists, but also C-style structs.

So to resolve it while keeping backwards compatibility, maybe Vizzy should allow to pass as argument either a reference or a copy of a list. Maybe let's just add a list expression copyOf. Then one could call methods (I mean custom instructions/functions) like:

• myMethod(myList, arg2, arg3, ...) - myMethod is passed a reference to myList. Every modification is reflected in the original list.
• myMethod(copyOf(myList), arg2, arg3, ...)- myMethod is passed a copy of the list, so even if it modifies it, original list remains unchanged.

What do you think? Should I report a separate bug for it?

@sflanker That's a great point. I will need to change it so the Set List instruction makes a copy of the list. Unfortunately, that might break some existing programs, but ultimately it needs to be done.

@AndrewGarrison Using Remove All and Add doesn't affect this issue. Because list instructions use mutative functions on the C# List＜String> type and setting variables uses the original List＜String> instance. I think the only way to make a copy of a list such that the copy isn't modified when the original is would be to initialize the new variable with create [] and then copy items over in a for loop using Add [ item [i] in [$original] ] to [ $copy ]. I would say you could just call this by design, however, the behavior changes when you save the flight and resume because the lists get serialized and then deserialized separately which makes the lists independent.

Thanks. In the meantime, I would recommend using Add (and Remove All From, beforehand if necessary).