[Suggestion:] Let no-static nested function to become closure immediately for directly using %var% Topic is solved

[V2User]

Since static nested functions were introduced in v2.0-bata6 and will never become closure as a complementary to closures, non-static nested functions should immediately become closure instead, first time and every time the outer function runs. There is no possibility and no reason whatsoever for non-static nested functions to duplicately do what static nested functions have already achieved and been specifically responsible for. It should always be closure as a clear and reasonable division of labor.
As it has been substantially "marked" as closure at the first time you write f(){, by whether it has static keyword fronted. It's time to make a change to give static nested functions which should have become a closure from the very beginning, a support to directly use %var% for outer variable's accessing and assignment, without any manually capturing.
It should be like this:

Code: Select all

f(){
	cc:='321'
	ff(){
		d:='cc'
		OutputDebug(%d%)
		%d%:=55
	}
	OutputDebug(cc)
}
f()

After getting rid of making complex internal rules and taking time to determine whether and when an inner function should become a closure, all the script program has to do is to check at the load time if the keyword static is not given. Obviously, it simplifies the internal rules for computers, but more importantly, it gives convenience to use %var% directly in a de facto closure for us.

[lexikos]

I think you are operating on one or more misunderstandings. The rules for which variables a closure captures are clearly defined in the documentation. Even if the nested function was a closure, it would not capture cc and therefore %d% would not work.

If a closure was to capture all local variables, including those which are not directly referenced by this or any other closure, any object references that are stored in a local variable would then not be released when the function returns, even if they are not used by the closures. Aside from increasing memory usage and other possible problems depending on the object, this increases the risk of unintentional circular references (such as when a closure is assigned to a local variable), preventing the closures and all local variables from being freed at all. Even if the local variables do not contain objects, overhead increases by some amount for each local variable that is captured unnecessarily.

Dynamic variables are rarely if ever the best solution to a problem, and are never the only option. Using an array or object instead of a collection of dynamic variables generally provides - as you put it - "a clear and reasonable division of labor."

[V2User]

Yes, I have to admit that you are quite right after a further thinking. Using %string%:= with a string to just access inner local variables in a closure is not safe and may cause unexpectedly capturing outer variables without a throw.