[vim/vim] Vim9 script: Type safety broken for nested lists through list<any> (Issue #19045)

[Peter Kenny]

kennypete created an issue (vim/vim#19045)

When accessing/amending nested lists through a list<any> parent, Vim's type checking loses track of actual types, leading to wrong type expectations, data corruption on failures, and allows type violations. The following short script demonstrates several issues:

vim9script
final inner: list<string> = ['a']
const OUTER: list<any> = [inner]
try
  OUTER[0][1] = 'b'  # Fails with E1012: Type mismatch; expected number!  Why?
catch
  echo v:exception
  # And it has corrupted inner, adding a zero:
  echo $"inner is now {inner} but is type {inner->typename()}"
finally
  # Adding a number to inner, via OUTER, works (adding to a list<string>)
  OUTER[0][2] = 1    # "Successfully" adds a number to a list<string>
endtry
echo $"OUTER is {OUTER}"
# inner still reports as a list<string> but is not, now being ['a', 0, 1]
echo $"inner is now {inner} but is type {inner->typename()}"

Actual behavior

• First assignment fails claiming it requires/expects a number
• On that failure, Vim corrupts the list, inner, by adding a 0
• Allows adding a number to the list<string>
• The type system reports list<string>, but it contains numbers, i.e., ['a', 0, 1].

Expected behavior

• OUTER[0][1] = 'b' should succeed (inner is a list<string>)
• Failures should not corrupt data
• OUTER[0][2] = 1 should fail because you should not be able to add a number to a list<string>.

Here it is in action (WSL Vim 9.1.1244; also, not shown, it's the same using gVim Windows 9.1.1943):

image.png (view on web)

—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/19045@github.com>