Pitch: @DependencyEndpoint generated properties

[maximkrouk]

Sometimes Clients API could be a bit more ergonomic if it could provide property accessors or even writable properties.

Currently we have

• Call-site access to getters using function calls
• If we need to specify a setter, it should be a separate DependencyEndpoint

Example:

@DependencyClient
struct ExampleClient {
  var getValue: () -> Int = { 0 }
  var setValue: (Int) -> Void
}

let client = ExampleClient(/*args*/)
let number = client.getValue()
client.setValue(number + 1)

It can be generalized if we make this client generic over Value, we can even make it callable as function to make it a bit more fancy

@DependencyClient
struct ExampleClient {
  var property: Property<Int>
}

let client = ExampleClient(/*args*/)
let number = client.property()
client.property(number + 1)
// not sure if it's actually better than explicitly accessing `Property` client props, it's just more fancy 💅

In any case it's not very ergonomic both at the call and declaration sites.
My proposal is to allow DependencyEndpoint to be attached to properties with the following processing

Declaration example:

struct CustomClient
  @DependencyEndpoint(property: .readWrite) // not sure about the naming here at all 😓
  var writableProperty: Int = 0

  @DependencyEndpoint(property: .readonly) // might be `getonly` or `computed` 🤔
  var _readonlyProperty: int = 0
}

var writableValue = 0
let client = CustomClient(
  _writableProperty: (
    { writableValue },
    { writableValue = $0 }
  ),
  _readonlyProperty: { Int.random(in: 0...10) }
)

client.writableProperty += 1
let randomInt = client.readonlyProperty

client._writableProperty.getter = { randomInt }
clinet._readonlyProperty = { 0 }

Expansion example:

public struct CustomClient {
  public var writableProperty: Int {
    get { _writableProperty.getter() }
    get { _writableProperty.setter(newValue) }
  }

  public var _writableProperty: (getter: () -> Int, setter: (Int) -> Void) = (
    {
      IssueReporting.reportIssue("Not set: '\(Self.self)._writableProperty.getter'")
      return 0
    }
    {
      IssueReporting.reportIssue("Not set: '\(Self.self).writableProperty.setter'")
      return 0
    }
  )

  public var readonlyProperty: Int {
    get { _readonlyProperty() }
  }

  public var _readonlyProperty: () -> Int = {
    IssueReporting.reportIssue("Not set: '\(Self.self)._writableProperty.getter'")
    return 0
  }
}

• We can also support async properties
• I'm not sure if tuples is the best solution, probably separate types will give us more control, simplify macors and it'll be more stable API overall

  In case of separate types we'll need: _Property, _ThrowingProperty, _AsyncProperty, _AsyncThrowingProperty, _WritableProperty(async/throwing props do not support setters)

[maximkrouk]

Also might make sense to create published/asyncPublished properties, I'm currently experimenting with property wrappers in a separate project, maybe at some point I'll rewrite them to macros and create a package or PR (if it makes sense to you to add those to the lib) 🤔