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

[Jose Cheyo Jimenez]

> On Dec 2, 2017, at 11:46 PM, Jean-Daniel <mailing at xenonium.com> wrote:
> 
> 
> 
>> Le 3 déc. 2017 à 04:58, Jose Cheyo Jimenez via swift-evolution <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. 


> 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/
> 
> @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/25dbd283/attachment.html>