Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to the review manager (me) via the forum messaging feature. When contacting the review manager directly, please keep the proposal link at the top of the message.
What goes into a review?
The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
What is your evaluation of the proposal?
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
Big +1, great to get this publically supported (we are using @_specialize today). Did a quick skim of the SE and it seems to be just formalizing what we use today (very happy to start seeing more and more underscored things being officially supported now as a side note ).
My only comment is that it would be nice to define groups of annotations and reuse them to reduce boilerplate, e.g. we have things like:
@inlinable
@inline(__always)
@_specialize(where T == OrdoPublic.Account)
@_specialize(where T == OrdoPublic.Incident)
@_specialize(where T == OrdoPublic.Instrument)
@_specialize(where T == OrdoPublic.Order)
@_specialize(where T == OrdoPublic.ProductGroup)
@_specialize(where T == OrdoPublic.PublicTrade)
@_specialize(where T == OrdoPublic.Plugin)
@_specialize(where T == OrdoPublic.PluginBundle)
@_specialize(where T == OrdoPublic.Resource)
@_specialize(where T == OrdoPublic.Transaction)
@_specialize(where T == OrdoPublic.User)
and then one needs to go and fix specialisation in multiple places.
It is a generic problem with function annotation, it would be great with something akin to typealises:
let @ourAnnotation = {
@inlinable
@inline(__always)
@_specialize(where T == OrdoPublic.Account)
@_specialize(where T == OrdoPublic.Incident)
@_specialize(where T == OrdoPublic.Instrument)
@_specialize(where T == OrdoPublic.Order)
@_specialize(where T == OrdoPublic.ProductGroup)
@_specialize(where T == OrdoPublic.PublicTrade)
@_specialize(where T == OrdoPublic.Plugin)
@_specialize(where T == OrdoPublic.PluginBundle)
@_specialize(where T == OrdoPublic.Resource)
@_specialize(where T == OrdoPublic.Transaction)
@_specialize(where T == OrdoPublic.User)
}
and then have use sites like:
@ourAnnotation
func xxx()
to apply all of those consistently in one go
it is another pitch though of course, but specialization really can make this blow up... Would be nice to reduce boilerplate somehow.
I think this would be covered well by one of the future directions:
Marking types or extensions as @specialized
It may desirable to mark a number of generic functions "en-mass" as specialized for a particular type, by annotating either the type or an extension grouping.
This would mostly be just sugar for annotating each function individually. The exception could be annotation of classes or protocols where an entire specialized witness or vtable could then be passed around and used from other unspecialized functions.
Right, but would also be nice to cover other annotations, those future directions only was for the specialization as far as I understood, but also things like:
would be nice - or even macros, but then we start to slide into preprocessor macro territory... I guess one could do it with macros, but not so convenient really.
Right. I think this is a very useful direction to explore, but it's in addition to this proposal, rather than something that needs to be bundled in with it, since it's more broadly useful. Worth noting that we have one very specific form of this already that we use for availability annotations on Apple platforms, but I can imagine it being generalized for this task as well.