{..} usage allows weird type-checks

[ryyppy]

I tried to explain {..} to another user and while typing out some examples I created a code snippet that actually compiled (even though I think shouldn't):

@val external someObj: {..} = "someObj"

someObj["name"] = "Patrick"
someObj["twitter"] = "@ryyppy"

someObj["name"] = 1

let myFn = (obj: {"name": string, "twitter": string}) => {
  Js.log(obj)
}

myFn(someObj)

IMO either it should have yielded a type error on the second name assignment, or at least error out in the myFn(someObj) call, since I'd expect someObj["name"] to be of type int.

Is this intentional?

[CarlOlson]

I think this is intentional. {..} is a concrete type, right? So assigning a property to it doesn't refine it (compared to Typescript for example). I've used this to quickly port JS code to non-idiomatic ReScript.

However, this will still compile:

@val external someObj: {.. "name": string} = "someObj"
someObj["name"] = 1

I feel like that should be an error. The compiler is treating getters and setters separately. Maybe that is useful to someone? 🤷

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.