1

I have this struct:

struct Foo {
    var name: String = "hello"
    var count: Int = 42
}

When I add @dynamicMemberLookup on it compiler rightfully complains:

So, I've added the relevant subscript implementation:

@dynamicMemberLookup
struct Foo {
    var name: String = "hello"
    var count: Int = 42

    subscript<T>(dynamicMember keyPath: WritableKeyPath<Foo, T>) -> T {
        get {
            fatalError("TODO")
        }
        set {
            fatalError("TODO")
        }
    }
}

and now compiler is happy.

However, it has no effect:

var foo = Foo()
foo.name = "bye"
print(foo.name)

and my subscript getter/setters are not getting called †.

Is this a bug? if this is a bug then what bug is this exactly:

  1. that it doesn't work (as "expected"), and it should.
  2. that compiler does accept this subscript as a valid dynamicMember implementation and it shouldn't.

(† I know how to make it work with a slightly different keypath subscript and a separate helper type, as discussed e.g. here).

2

Honestly I'd expect that the compiler prioritises the get/set of Foo itself, why I guess the subscript is not called.
Is there a particular reason why you'd like to have dynamicMemberLookup with members being the members of the type where the attribute is applied to?

3

Don't you think it's strange that compiler accept it as a requirement and then simply ignores it?

I'm exploring various observation machinery implementations. See the relevant thread.