OpenAPIObjectContainer API weirdness, `init` validates value but then allows me to set anything into `.value`

[weissi]

Description

OpenAPIObjectContainer's API has a bug:

public struct OpenAPIObjectContainer: Codable, Hashable, Sendable {
// public
    public var value: [String: (any Sendable)?]
    public init() { self.init(validatedValue: [:]) }
    public init(unvalidatedValue: [String: (any Sendable)?]) throws {
        try self.init(validatedValue: Self.tryCast(unvalidatedValue))
    }

// internals
    init(validatedValue value: [String: (any Sendable)?]) { self.value = value }

Basically the public inits force me to go through validation (and throw) but the setter for self.value accepts anything. So I can write

struct BadGuy: Sendable {}

var c = OpenAPIObjectContainer()
c.value["bad"] = BadGuy()

which now gives me a "validated" OpenAPIObjectContainer without validation.

Reproduction

see above

Package version(s)

runtime 1.8.0

Expected behavior

won't let me set bad stuff

Environment

6.2

Additional information

No response

[weissi]

My fix suggestion would be:

1. Deprecate the setter
2. Make the (deprecated) setter validate and ignore the newValue if validation fails
3. Provide a new setValueValidating(_ value: ...)

[simonjbeaumont]

Thanks for filing. That seems like a reasonable approach to address this.

[czechboy0]

which now gives me a "validated" OpenAPIObjectContainer without validation

Strictly speaking, OpenAPIObjectContainer isn't guaranteeing that it contains validated data, just offers an initializer that itself validates. You could, for example, construct a similarly invalid instance using a custom decoder.

That said - I agree that flexibility doesn't seem useful, and might even be harmful.

My lean here would be:

1. Deprecate the setter
2. Add a throwing, validating setter instead

I wouldn't change the behavior of the existing setter though, beyond deprecating it.