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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
