<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 10, 2015, at 2:30 AM, Tommy van der Vorst <<a href="mailto:tommy@pixelspark.nl" class="">tommy@pixelspark.nl</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><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></div></blockquote><div><br class=""></div><div>You wouldn’t define a static runtime check directly. That's the responsibility of external tools. Swift linter tools have already started to appear, though I don’t think any of them are taking advantage of the compiler tooling yet. User defined annotations would give them a lot more options and potential power and help motivate an ecosystem. You could imagine a way to have pluggable checks be part of the core language infrastructure, but that seemed out of scope.</div><div><br class=""></div><div>As an example of a check, there was a previous discussion of a scope based access control modifier. It would be relatively straightforward to define an attribute for that and linter pass for it, see if people find it has value and if so, feed it back into the core language.</div><div><br class=""></div><div>Some other off the cuff examples of annotations include:</div><div>1. Key-value observable</div><div>2. Must call super</div><div>3. Animatable (as mentioned by Rudolf)</div><div>4. Should be on main thread</div><div>5. Side effect free</div><div><br class=""></div><div>Some of these are just for standardizing documentation, and some could have actual checks associated with them.</div><div><br class=""></div><div>I haven’t looked at this closely, but I expect it would allow several existing attributes, like IBAction and friends, to move out of the core language and into libraries.</div><div><br class=""></div><div>Further, part of the point of custom annotations is to allow the community to experiment with new features without having to accept them into the core language. Having a feature like this helps prepare for whatever good ideas people have later. Some of those ideas will of course, not be good, but by allowing them to start out as user defined tags we can validate them and find the ones that have real value. You can see this sort of thing happening in the Java community around annotations like @Override and @Nonnull.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><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></div></blockquote><div><br class=""></div><div>I think having the compiler check that your annotations exist has value. Typos are easy to make.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><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></div></blockquote><div><br class=""></div><div>Yeah, these are useful features for sure and annotations could go that way in the long term. This proposal is more of a stake in the ground to get things started and help inform the direction of those designs, while also providing enough initial value to be worthwhile on its own.</div></div><div class=""><br class=""></div><div class="">-Akiva Leffert</div><div class=""><br class=""></div></body></html>