Entry of which key is same with an element index

[taichi-ishitani]

Hi,

As shown example below, entries of which key matches with an element index will be deleted.

foo { [0] = 2; 3 }
bar = foo[0]

$ ./pkl eval foo.pkl
foo {
  3
}
bar = 3

On the other hand, entries of which key does not match with an element index will not be deleted.

foo { [1] = 2; 3 }
bar = foo[0]

$ ./pkl eval foo.pkl
foo {
  [1] = 2
  3
}
bar = 3

Which behavior is wrong?

[bioball]

Currently, there is a bug when mixing entries whose keys are integers with elements. So, the first snippet is incorrect, and is a bug.

This happens because Pkl mistakenly interprets [0] = 2 as "assign to element with index 0", instead of "declare an entry with key 0".

[taichi-ishitani]

Thank you and I understood. For the first example, what is the expected value of foo[0]? Should it return the element with index 0?

[translatenix]

Currently, there is a bug when mixing entries whose keys are integers with elements. So, the first snippet is incorrect, and is a bug.

What does [n] = x mean for Dynamic? Does it mean the same as for Listing, the same as for Mapping, or something else?

[bioball]

Currently, the behavior is: if there is an element at index n, [n] = x means: overwrite element at that index. And foo[0] means either "get element with index 0`, or "get entry with key 0", depending on which exists. In our current model, it is not possible to for entries with number keys to coexist with elements at the same number index.

With our current behavior, I think this should throw with a duplicate member definition error. It doesn't make sense for this to be accepted as one element declaration:

foo { [0] = 2; 3 }

I think there's some room for improvement here. This is surprising:

bar {
  1
}

foo = (bar) {
  [0] = 0
  [1] = 1
  [2] = 2
}

This produces:

bar {
  1
}
foo {
  0
  [1] = 1
  [2] = 2
}

Possibly, we can change the grammar for "assign to element index N", which might help here. For example, here's some made up syntax:

foo {
  amend [0] = 0
}

[taichi-ishitani]

I think this should throw with a duplicate member definition error.

Is it expected behavior that Pkl raise an error if an entry and an element have the same idnex? I'm developing a Pkl parser written in Ruby so I post this issue.