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

[Cheyo Jose Jimenez]

> On Dec 3, 2017, at 12:44 PM, Jean-Daniel <mailing at xenonium.com> wrote:
> 
> 
> 
>> Le 3 déc. 2017 à 09:29, Jose Cheyo Jimenez <cheyo at masters3d.com <mailto: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.

This is assuming that the protocol is what triggers the compiler to treat this type differently (Current draft implementation).

Currently in the draft there are 2-3 protocols that give the dynamic behavior to a type. These protocols can be typealias'ed, conformed by other protocols with different names etc. 

________________________
**someModule.swift***

public protocol JustAnotherProtocol: DynamicCallable {...}
________________________

**myModule.swif***

struct JSVal: JustAnotherProtocol {...}
________________________


How do I know JustAnotherProtocol is dynamic in a git diff?

Having a common sigil like @IamDynamic can make all these declarations explicit. Clearer to the reader. All other related dynamic protocols can share the same umbrella sigil. 

Chris added it to the list of potential solutions.
https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438#reducing-potential-abuse <https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438#reducing-potential-abuse>

"
We could add an attribute or use some other way to make conformance to DynamicMemberLookupProtocol more visible, e.g.:
@dynamic
struct PyVal : DynamicCallable {...}
"



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