'@dynamicMemberLookup' requires 'subscript(dynamicMember:)'
to be as accessible as its enclosing type; this will be an error in a
future Swift language mode
i find private dynamic member lookup to be an incredibly useful feature. any reason why it is being removed?
What happens if someone publicly adds subscript(dynamicMember:) in an extension of your @dynamicMemberLookup type?
If @dynamicMemberLookup were added to the language today, I suspect it would be spelled as a (marker?) protocol.
@dynamicMemberLookup is a syntactical construct, so i imagine it would behave exactly the same as if you tried to call the subscript explicitly, given the same set of hypothetical overloads.
I think the bug this was trying to fix was that you could circumvent access control entirely and use a private dynamic member subscript from outside the type’s scope.
It sounds like what you’re after is a type that has a dynamic member lookup interface that’s internal to the type only, and not visible from the outside?
I’m guessing specifically banning that wasn’t the intent here, but maybe nobody thought of that use case at all.
Yeah that’s a good point too. The @dynamicMemberLookup attribute is as visible as the type itself, so if the subscript is less visible than the type, someone else can come along and invent their own more visible subscript in front of your type.
In retrospect, I wonder if we should have required the subscript to be declared on the main type declaration, just as the attribute must (can only) be, since the dynamic lookup is sort of an innate quality of the type.
Though maybe this would interfere with the key path version if someone was adding them conditionally based on generic types...
My intent when introducing this diagnostic was to solve a swiftinterface issue, but I think the restriction is generally justified because as you say the attribute is as visible as the type. There are other similar attributes like @resultBuilder that imply the type implements some interface and the declaration checker requires that interface to be as accessible as the type and this seems very similar to me.
We could solve the swiftinterface issue a different way if necessary, but before we do that I’d like some confirmation that allowing a less visible implementation of @dynamicMemberLookup was an intentional feature rather than a longstanding oversight.