<div dir="ltr">Hi,<div><br></div><div>This is yet another idea had been discussed but had no real conclusion. I find this could be very useful for the framework developers, here is my draft proposal.</div><div><br></div><div>First I should explain why this is useful for framework developers, let&#39;s take some example:</div><div><br></div><div>1. add annotation to class to generate extension for <span class="" id=":2ze.1" tabindex="-1">JSON</span> parsing and serialization.</div><div>2. add annotation to property or function to generate glue code for exporting to <span class="" id=":2ze.2" tabindex="-1">Lua</span> script.</div><div>3. add annotation to function or class to generate c/objective-c and java source for bridge <span class="" id=":2ze.3" tabindex="-1">JNI</span> call.</div><div>4. add annotation to function or class to generate objective-c++ glue for bridge c++ call.</div><div>5. add annotation to function or class to dynamically bind shared library</div><div>6. add annotation to class to generate stub/skeleton call for your favorite <span class="" id=":2ze.4" tabindex="-1">RPC</span> framework</div><div>7. add annotation to class to generate stub call for your favorite database framework</div><div>8. etc... anything that can be systematically generated</div><div><br></div><div>Some of the problem can be solved with generic function, but many are not, especially swift generic is a bit limited compared to C++ template.</div><div><br></div><div>Traditionally user defined annotation are for declaration only, and basically a <span class="" id=":2ze.5" tabindex="-1">runtime</span> feature that paired with reflection.</div><div>I did not find this arrangement particularly useful, and actually have some shortcoming:</div><div><br></div><div>1. you need to actually store the annotation in final binary</div><div>2. it would help reverse engineering/hacking</div><div>3. <span class="" id=":2ze.6" tabindex="-1">runtime</span> reflection is slow</div><div><br></div><div>So, why not just make the annotation and processing a compile time feature?</div><div><br></div><div>Application developer (user of framework) can annotation the source, the annotation processor (written by framework developer) can read the annotation and generate source code for further compile (not necessary limited to generate swift only)</div><div><br></div><div>Of course, there are many difficulty with this approach, you have to revise the compile processing pipe-line, build/make tool need to be revised too, etc... But I think it did bring a lot of value to swift, especially when you need to integrate swift with external framework or service.</div><div><br></div><div>There are many things need to be done to implement this feature:</div><div><br></div><div>1. Syntax for annotation, I would suggest:</div><div><br></div><div>@[ MyAnnotation1(), MyAnnotation2(option: &quot;xxx&quot;, force: false) ]</div><div><br></div><div>It looks like old-time objective-c array, each element is an instance of sub-class of Swift.Annotation, you can attach it alongside with built-in annotation.</div><div><br></div><div>2. The processor should implement protocol Swift.<span class="" id=":2ze.7" tabindex="-1">AnnotationProcessor</span>&lt;T: Swift.Annotation&gt; , the protocol contract need to be determined later.</div><div><br></div><div>3. Need a way to forward declare function, so the annotation processor can emit function implementation later.</div><div><br></div><div>4. Need a way to represent the class/method/etc code model for annotation processor, much like reflection interface, but for compile time and with declaration only.</div><div><br></div><div>5. And we need to divide compile pipeline into at least two phase, etc..</div><div><br></div><div>Anyway, we can always discuss the implementation later, giving all these difficulties, I want to know your opinion about this arrangement and is it worth the trouble? What do you think?</div><div><br></div><div><br></div></div>