`[key]value` map can cause runtime network errors

Summary

I run into a very odd situation that was easily overlooked as the verse compiler didn’t yield any errors not even warnings about a key-type mismatch. This caused the code to compile without any issues but always produce a runtime network error that leads to a full disconnection from the UEFN session.

Please select what you are reporting on:

Verse

What Type of Bug are you experiencing?

Verse

Steps to Reproduce

key_enum := enum { A }

Test(): void = {
  var Map: [tuple(string, key_enum)]int = map {}

  # WARNING: This container lookup is unlikely to succeed. (Did you mean to use a different key?) (2017)
  Map[42] or 1

  # Nothing, the compiler is perfectly happy with this key-type mismatch.
  Map["string"] or 2
}

Expected Result

Key-type mismatches should be compiler errors, it should not be relaxed to warnings!

  • Map[42] aka warning (2017) should be an error
  • Map["string"] should be an error

Observed Result

Mismatches like Map[42] are only warnings, which can be ignored and will likely also cause network errors at runtime.

Map["string"] mismatch is more critical as it’s completely silent and potentially very hard to spot in the code base. It caused network errors at runtime every time the read operation was performed.

Platform(s)

UEFN (v36.20)

The way I personally trapped myself with this was a type update due to a refactor. The type went from [string]value to [tuple(string, some_enum_type)]value. All compiler errors were fixed except that the compiler didn’t highlight the key-type mismatch for some read operations, which were still using the string key. I consider this compiler behavior in a strongly typed language as bad and it should be addressed as it’s too easy to run into, but is not trivial to find and fix. Furthermore I’m very much surprised that other key-type mismatches are warnings instead of errors.

FORT-942645 has been created and its status is ‘Unconfirmed’. This is now in a queue to be reproduced and confirmed.