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 {


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.


swift-evolution mailing list

Reply via email to