Macro-based declarative config

[czechboy0]

This would sit fully on top of the existing imperative ConfigReader API.

Open to ideas, we might even want to coordinate with the new Codable effort: https://forums.swift.org/t/the-future-of-serialization-deserialization-apis/78585 - as the property macros might have similar requirements.

[Malien]

KeyPath based API

Here's a prototype of one of the ways we can go: https://gist.github.com/Malien/59b1d764b610ae02710103798cfa09a2

There are limitations of course. The idea being to not eagerly parse and validate the config (that's what design relying on Codable would have to be limited to)

I am not sure if this KeyPath based API is the best way to go though. I think synthesizing computed properties might provide a more "intuitive" API, although not without its quirks.

An explicit call to .get(_:) would subconsciously signify that the value might change, whereas accessing the property on a struct might give a false sense of immutability.

Lazy accessors

@ConfigShape
struct HTTPConfig /* synthesized conformance */ : ConfigShape {
  var hostname: String?
  var port: Int = 80
  var bindAddr: String
  var tls: TLSConfig

  // which synthesizes
  struct Proxy: ConfigProxy {
    var reader: ConfigReader
    init(reader: ConfigReader) { self.reader = reader }
 
    var hostname: String? { reader.string("hostname") }
    var port: Int { reader.int("port", default: 80) }
    var bindAddr: String { 
      get throws { try reader.requiredString("bindAddr") }
    }
    var tls: TLSConfig.Proxy { .init(reader: reader.scoped(to: "tls")) }

    func fetchHostname() async throws -> String? { ... }
    func fetchPort() async throws -> String? { ... }
    func fetchBindAddr() async throws -> String { ... }

    // and watchHostname, watchPort, watch etc variants
    // I think an explicit fetch function might be better than 
    // async var asyncHostname { get async {} }
  }
}

protocol ConfigProxy {
  init(reader: ConfigReader)
}

protocol ConfigShape {
  associatedtype Proxy: ConfigProxy
}

let config = reader.typed(as: HTTPConfig.self)
config.hostname
config.tls.certPath

This would continue to ensure the lazyness that the current package prescribes.

Eager deserialization

Of course one could instead synthesize an init, that takes a reader, and eagerly reads all of the properties.

@ConfigShape
struct HTTPConfig {
  var hostname: String?
  var port: Int = 80
  var bindAddr: String
  var tls: TLSConfig

  // Synthesized
  init(fromConfig reader: ConfigReader) throws {
    self.hostname = reader.string("hostname")
    self.port = reader.int("port", default: 80)
    self.bindAddr = try reader.requiredString("bindAddr")
    self.tls = try .init(reader: reader.scoped(to: "tls"))
  }
}

let config = try HTTPConfig(fromConfig: reader)

A challenge would be to keep the values up-to-date when the fetch updates with the new value or reactive providers yield new values. This .init(fromConfig:) would essentially make a snapshot.

---

None of these solutions address the concept of optional namespaces explicitly. aka:

@ConfigShape struct ApplicationConfig {
  var http: HTTPConfig
  var devServer: HTTPConfig? // if not provided, will not start a dev server
}

The idea being: either you have not defined anything under devServer key, or if you did, you have fulfilled all the required fields.

With the lazy API, checking that the config key namespace is present, is likely to require falling back to the eager checking.

if let devServer = config.devSever {
  setupHTTPServer(config: devServer)
}

Nice to have

@ConfigProperty (or whatever it gets called) has to have the ability to specify an alternative key name, isSecret, as: ExpressibleByConfig*

@ConfigProperty(key: "mycoolkeyname")
var foo: String?

@ConfigProperty(.inline) // don't nest under the "tls." prefix
var tls: TLSConfig

@ConfigProperty(.redacted)
var password: String

@ConfigProperty(from: .string)
var cron: MyCronTypeExpressibleFromConfigString = "* * * * 60 * *"

[czechboy0]

Thanks @Malien, this is a great exploration. The eager approach was also what I was thinking, and I also like the proxy idea for fetch/watch.