`decode.field` traverses prototype chain on JS target

[jtdowney]

On the JavaScript target, decode.field (and probably decode.at and decode.subfield) succeed for keys inherited from Object.prototype (like toString and constructor). The Erlang target reports these as missing. The same Gleam source compiled for the two targets, therefore, produces different decoder results on the same input.

import gleam/dynamic/decode
import gleam/io
import gleam/json
import gleam/string

pub fn main() {
  let decoder = {
    use name <- decode.field("toString", decode.dynamic)
    decode.success(string.inspect(name))
  }

  let value = json.parse("{}", decoder)
  io.println(string.inspect(value))
  // JS: Ok("//fn() { ... }")
  // Erlang: Error(UnableToDecode([DecodeError("Field", "Nothing", ["toString"])]))
}

Using Object.hasOwn instead of the in keyword should prevent this.

[lpil]

Hello! Why should we prevent this?

[jtdowney]

I would say because it's surprising and incorrect behavior caused by the prototype inheritance leaking into gleam. The correct version is simple enough and if you want exposure to the prototype system that's what FFI is for.

[jtdowney]

The more I've thought about this this morning, the more I've come around to the idea that while this is surprising (to me), it may actually be the correct behavior for a general decoder.