[swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

[Letanyan Arumugam]

I see that this feature is fully type safe and has behaviour that is precedent in the language today (It is just sugar after all). I still feel like it is not safe by default and doesn’t discourage the use dynamic programming over static.

----Obviously for the latter if Swift doesn’t/shouldn’t have a preference between the two then by all means disregard as a reason for this design.

A way I see to accomplish both of these simultaneously is to have types that conform to DynamicMemberLookup is to force them to write subscripts that return optionals (and later throws if that ever gets support). To get return types that aren’t Optional a type would have to use a @unchecked attribute on the protocol conformance.

For Example:

enum JSON : DynamicMemberLookup {
	subscript(dynamicMember: String) -> JSON {
		...
	}
}

would be a compile error, where as:

[*]
enum JSON : @unchecked DynamicMemberLookup {
	subscript(dynamicMember: String) -> JSON {
		...
	}
}

OR

enum JSON : DynamicMemberLookup {
	subscript(dynamicMember: String) -> JSON? {
		...
	}
}


would work fine.

I think one should also be able to override @unchecked and make conforming types checked.
So following on from the code example [*] if I were to write

extension JSON : @checked DynamicMemberLookup {}

then later dynamic member lookups would wrap the results in an optional.

Supporting this the other way (make a type unchecked) might not be ideal since the author of the type saw it unfit to have it unchecked and we should probably respect that.


I’m aware of #3 of “Reducing Potential Abuse” in the proposal however that option is not well expanded. So I’m not sure if this falls into that.

-Letanyan



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171206/934222b1/attachment.html>