[swift-evolution] [Pitch #2] Introduce User-defined "Dynamic Member Lookup" Types

[Jean-Daniel]

> Le 3 déc. 2017 à 09:29, Jose Cheyo Jimenez <cheyo at masters3d.com> a écrit :
> 
> 
> 
> On Dec 2, 2017, at 11:46 PM, Jean-Daniel <mailing at xenonium.com <mailto:mailing at xenonium.com>> wrote:
> 
>> 
>> 
>>> Le 3 déc. 2017 à 04:58, Jose Cheyo Jimenez via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> a écrit :
>>> 
>>> Hi Chris, 
>>> 
>>> 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 ?  
> Won’t compile?
> 
>> What this attribute will mean on an other declaration ?
> Won’t compile?
> 
> It would be similar to the swift 4 mode where @objc is required in some declarations. 

No it isn’t.
Like with @NSManagedObject, the very same declaration can exist with or without the @objc attribute depending the context, and the behavior of the function change. Neither is true with the @dynamic proposal.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171203/15022fae/attachment.html>