Validating exact fields of object literals

[EvanBalster]

I'm trying to define a type for an object literal for a table representing miscellaneous extra options in a function. Currently I've defined the type like so in a @meta file.

---Literal type for specifying miscellaneous options in scan-type functions.
---@class (exact) ScanOptions
---@field line_of_sight boolean|nil   Enable/disable line of sight limitation (much faster).  Default varies.
---@field center        vec2|nil      Center point of the scan.  Default: this object's position.
---@field frame         trans2|nil    Transform applied to resulting ObjectViews. Default: none (ie, this section's coordinates)
---@field portal_limit  integer|nil   Max number of portals between starting point and scanned objects.
---@field promote       MapStatus|nil Promote sections in scan radius up to this level.
---@field promote_limit integer|nil   Max number of sections that may be promoted.
ScanOptions = {}

This type is then used as an optional argument to this function: (this is a bound C++ function so again, only @meta info)

---List all Aspects of type T in objects near to this Object.
---@generic T
---@param select_type T        Aspect type.
---@param radius_m number      Radius in meters.
---@param options? ScanOptions  Optional extra settings for the scan.
---@return fun(): T, ObjectView
function Object:scan(select_type, radius_m, options) end

The problem is that this doesn't seem to validate { object literals }. Marking the ScanOptions class as (exact) will flag any rogue assignment but won't give any warning about invalid fields in the brace-initialized object:

The diagnostics will complain if I try to initialize a field with the wrong type (eg, line_of_sight=1). But no respect for that (exact) flag. Did I overlook something?

[tomlau10]

Did I overlook something?

Yes, you overlooked that there are already issues reporting this: 😂

• table validation is not working as expected #3040
• a comment within the mega thread about exact class
  [Feature Request] Add a strong typed struct/class that cannot assign a new field that is not defined in the struct/class. #1990 (comment)
• Exact classes can have fields injected when used as parameters to funcitons #2288
• Table literals aren't properly checked for field injections and missing fields #2802

[EvanBalster]

Ah. I did a search for issues related to "table literal" which seems to be the crux of the problem but didn't manage to spot #2802.