$parse().assign() for expression with numeric index creates object instead of array

[zgmnkv]

http://jsfiddle.net/bdwpnr5c/1/

<input ng-model="model[0]"/>
<pre>{{ model | json }}</pre>

gives

{
  "0": "value"
}

but expected result is

[
  "value"
]

Expected result could be achieved with manual assigning array value to model

<div ng-init="model = []"></div>
<input ng-model="model[0]"/>
<pre>{{ model | json }}</pre>

but it's not always easy to handle for complex objects (like model[0].prop.arrayProp[1].innerProp)

It should be easy to check if key is numeric and create array instead of object in this case.
Thanks

[pkozlowski-opensource]

So, I'm not sure we really want to fix this one as this is kind of corner case and we might have funny situations like this:

<input ng-model="foo.bar.a">
<input ng-model="foo.bar[0]">

So depending on which input gets filled in first a different object type will be created. Additionally it is very easy to create "big" arrays by simply doing .

I guess this is a breaking change as well but oh, I can see cases where this could be useful and since fix is trivial here is a PR: #9850. Let's see what others think about this one.

[zgmnkv]

I think that ng-model="foo.bar.0" should not be handled anyway, because it's not valid javascript expression, property name shouldn't start with digit.

If talking about the case like this:

<input ng-model="foo.bar.a">
<input ng-model="foo.bar[0]">

then I don't see anything strange when type of bar will be defined by first filled input. It's the same situation as if we use different input types on the same model (e.g. date and text). It's a developer job to handle this.
And if we want always to create object, we can do

<input ng-model="foo.bar.a">
<input ng-model="foo.bar['0']">

[pkozlowski-opensource]

@zgmnkv yeh, I've meant foo.bar[0] - updated me comment.

Regarding this functionality - I think you need to do some more lobbing if you want this to land in master as many people (including me) feel 50/50 about it.

Anyway, the PR is there, let's see how other people are weighting this one.

[zgmnkv]

Ok, thanks for the PR anyway!

[pkozlowski-opensource]

OK, so we seem to have another issue for this: #5806

[pkozlowski-opensource]

Closing this one as "won't fix" based on the discussion in the PR #9850