> On Dec 3, 2017, at 12:44 PM, Jean-Daniel <[email protected]> wrote:
>
>
>
>> Le 3 déc. 2017 à 09:29, Jose Cheyo Jimenez <[email protected]
>> <mailto:[email protected]>> a écrit :
>>
>>
>>
>> On Dec 2, 2017, at 11:46 PM, Jean-Daniel <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>>>
>>>
>>>> Le 3 déc. 2017 à 04:58, Jose Cheyo Jimenez via swift-evolution
>>>> <[email protected] <mailto:[email protected]>> 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 {...}
"
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
