Update loop syntax for arrays and objects, deprecate $index and $key

[chrisvfritz]

Deprecating $index and $key

Both of these are being deprecated in favor of more explicit named indices and keys. This syntax is a bit magical and has limitations in nested loops. As a bonus, there will be two fewer points of syntax for newcomers to learn.

New array syntax

• value in arr
• (value, index) in arr (switched order of arguments to be more consistent with JavaScript's forEach and map)

New object syntax

• value in obj
• (value, key) in obj (switched order of arguments, partly to be more consistent with many common object iterators, such as lodash's)
• (value, key, index) in obj (index will now be available in object iteration for visual purposes, such as table striping)

[simplesmiler]

How would this be supported in 2.0-migration?

[yyx990803]

@simplesmiler as of now I don't think it's feasible to provide a "seamless" migration build like the 0.12 to 1.0 upgrade, due to how much underlying implementations have changed. The deprecation warnings will mostly be used for features that can be simulated.

[prog-rajkamal]

@yyx990803
I believe this can be simulated in 2.0-migration by adding an optional parameter oldArgsOrder which defaults to true in 2.0-migration build and false in 2.0 build.

This is how it will work:

• 2.0-migration build, using 1.0 syntax will give warnings to switch order and use oldArgsOrder = false, default is true in this build.
• In 2.0 build, using oldArgsOrder parameter will encourage new syntax as default and mark this feature as deprecated for 3.0+

It certainly does not look like elegant but I prefer it over no seamless-migration build.

I don't what other problems which you are facing. But I am certain that seamless migration is possible with some workarounds which many will find acceptable.

[yyx990803]

@prog-rajkamal hmm, that's a good idea. Toggle between incompatible interfaces using flags would definitely make a migration build more feasible.