[swift-evolution] [Pitch #2] Introduce User-defined "Dynamic Member Lookup" Types
Jean-Daniel
mailing at xenonium.com
Sun Dec 3 01:46:54 CST 2017
> Le 3 déc. 2017 à 04:58, Jose Cheyo Jimenez via swift-evolution <swift-evolution at swift.org> a écrit :
>
> Hi Chis,
>
> Thank you for pushing this forward.
>
> My only comment is that on the declaration side it would be great to also have an attribute to communicate that compiler magic is happening.
>
> Currently it is surprising that a regular looking protocol is providing me so much power.
>
> Suggestions:
>
> @dynamic
> struct PyVal : MemberLookupProtocol {...}
>
> @dynamic
> struct ParameterSummer : DynamicCallable {...}
>
> // Error: This type needs the @dynamic attribute.
> class ParamWinter : MyCustomCallableProtocolOrClassOrTypeAlias {...}
>
> By requiring @dynamic (Or other attribute name), people can know that this is a compiler dynamic declaration and not just some random protocol whose name starts with Dynamic*. :)
>
I’m not fond of the idea of an attribute. This introduce redundancy. What a declaration means if the attribute is missing ? What this attribute will mean on an other declaration ?
If this attribute must be used with the declaration and it can’t be used with an other one, then what is the point of having an attribute but to exercice the compiler fixit feature
> @NSManagedObject is another example I like from Core Data.
> https://useyourloaf.com/blog/core-data-code-generation/ <https://useyourloaf.com/blog/core-data-code-generation/>
@NSManageObject apply to normal declarations that have a different meaning when this attribute is not present.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171203/dedcf72a/attachment.html>
More information about the swift-evolution
mailing list