> Le 3 déc. 2017 à 09:29, Jose Cheyo Jimenez <ch...@masters3d.com> a écrit : > > > > On Dec 2, 2017, at 11:46 PM, Jean-Daniel <mail...@xenonium.com > <mailto:mail...@xenonium.com>> wrote: > >> >> >>> Le 3 déc. 2017 à 04:58, Jose Cheyo Jimenez via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@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.
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
