<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Just chiming in here to say that I've always wanted to add something like @animatable to all animatable properties for my classes. It'd be so much better than searching docs.</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">R+</div><div id="AppleMailSignature"><br>Sent from my iPhone</div><div><br>On 10 Dec 2015, at 08:30, Tommy van der Vorst via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><div class="">Hi Akiva,</div><div class=""><br class=""></div><div class="">You mention documentation/linting and static checks - could you elaborate a bit on what <i class="">exactly</i> the use case for user-defined annotations would be for these things? How would one define a static runtime check in your proposed syntax? </div><div class=""><br class=""></div><div class="">For documentation, it would perhaps suffice if the compiler just ignored any 'unknown' annotations, but would provide them to external lint/documentation tools. Then again we already have documentation comment blocks.</div><div class=""><br class=""></div><div class="">A few other use cases I can think of: serialization (annotate field name to property), concurrency (so you can implement something like @synchronized) and reflection. Not sure whether any of these are in scope for Swift 3.0 though.</div><div class=""><br class=""></div><div class="">Best,</div><div class="">Tommy.</div><br class=""><div><blockquote type="cite" class=""><div class="">Op 10 dec. 2015, om 06:40 heeft Akiva Leffert via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> het volgende geschreven:</div><br class="Apple-interchange-newline"><div class=""><div class="">Hi,<br class="">I’m interested in adding user defined annotations. For example,<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>```<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>@MyAnnotation func foo() {<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>}<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>```<br class=""><br class="">This would help enable third party linting and behavioral documentation. This is useful in its own right, but it can also help inform the future direction of static checks within the language.<br class=""><br class="">I’ve started hacking on this (adding a new “Annotation” attribute and associated declaration), but I figured before I went too far I should get some feedback.<br class=""><br class="">—<br class=""><br class="">I imagine you would declare one of these in the following way:<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>```<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>annotation MyAnnotation<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>```<br class=""><br class="">and use it as above, using a qualified path if necessary: ``@MyModule.MyClass.MyAnnotation``.<br class=""><br class="">You could also imagine just having a single extendable attribute that takes a string, similar to how C compilers do it, ``@Annotate(“whatever”)`` but that seems error prone and really only works in C because you #define it once and count on the preprocessor to avoid typos. It also doesn’t help prepare for more interesting annotation usage later.<br class=""><br class="">As such, this would introduce a new keyword “annotation”. I think these are sufficiently useful - especially if they end up tying into a macro system - that they deserve a keyword. However, an alternate approach is to overload the existing attribute syntax:<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>```<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>@Annotation(MyAnnotation)<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>```<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>or<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>```<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>@annotation MyAnnotation<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>```<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>To me this seems awkward, as it does not match the style of any other declarations, but adding a new keyword is a big deal, so there’s an obvious trade off.<br class=""><br class="">This proposal does not include annotations with arguments nor does it ascribe any dynamic behavior to those annotations. The static content is limited to checking whether the annotation is already defined.<br class=""><br class="">I deliberately skipped arguments for annotations since there are a lot of questions about defining the types of those arguments, but it's an obvious future extension.<br class=""><br class="">Other possible extensions this proposal needs to not prevent:<br class=""><br class="">1. Providing annotations that actually do things like:<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>- Evaluate macros<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>- Connect to a protocol or class in some way a la java<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>- Python style decorators<br class="">2. Limiting annotations to certain syntactic classes.<br class="">3. New built in attributes.<br class="">4. <Insert your feature idea here><br class=""><br class="">This initial version is sufficiently minimal that I don’t think any of those would be blocked by it*.<br class=""><br class="">It’s not obvious to me what is the right way to scope user annotations vs new compiler ones. A simple namespace might be best, forcing the compiler to use “_” or lowercase or something like that, but that would involve further migration for existing code.<br class=""><br class="">Anyway, I’m happy to write this up into a proper proposal if there’s general interest.<br class=""><br class=""><br class="">-Akiva Leffert<br class=""><br class="">* Strawman examples of being compatible with possible extensions<br class=""><br class="">// arguments<br class="">annotation Foo(A, B, C)<br class=""><br class="">// macros<br class="">annotation macro Bar(A, B, C) {<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>… do stuff ...<br class="">}<br class=""><br class="">// decorators<br class="">annotation func Baz(f : Int -> String) -> (Int -> String) {<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>… do stuff ...<br class="">}<br class=""><br class="">// only certain syntactic classes<br class="">annotation Foo { usage { func, decl, struct, class } }<br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></div></blockquote></div><br class="">
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=j4IybsUIPYHiRcwUyRdFad0kPCzKStYJJlRNfGSc7oJ2wq0LB4CgEsClO9E8gLscCb4FQCKdPZYBGqrBfDxkt8Pwb-2FcuOJViYTYDUONvLQOaT46Twd2lxsu2G1MoIesN9Ut-2FXTbhJC-2Fbzflj-2BNBsicoWGsdengSqiGUEZQVT-2BCfjOAds95SyGtkWGJwKSNQD8QPQFUcTQU-2F4VAWFz0va9g-3D-3D" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;">
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>