SE-0460: Explicit Specialization

Evolution Proposal Reviews
1

Hi everyone,

The review of SE-0460 Explicit Specialization begins now and runs through February 11, 2025.

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?

More information about the Swift evolution process is available at https://github.com/swiftlang/swift-evolution/blob/main/process.md .

Thanks for contributing to Swift!

Steve Canon
Review Manager

12 Likes
2

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.

5 Likes
3

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.

1 Like
4

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.

1 Like
5

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.

2 Likes
6

First off, big +1 for this proposal. I have utilized the @_specialize attribute a number of times for boosting the performance of internal and external APIs in a number of different scenarios but have never felt fully comfortable using the underscored attribute.

Secondly, I have two questions that I haven't seen addressed in this proposal nor here in the forums:

  1. Would this @specialized attribute also support Integer Generic Parameters, like those laid out in SE-0452? For example:
// Using `InlineArray` from SE-0453
@specialized(where size == 1)
@specialized(where size == 2)
@specialized(where size == ...)
func sum<let size: Int, T: BinaryInteger>(_ numbers: InlineArray<size, T>) -> Double {
  var result: Double = 0.0
  for i in numbers.indices {
    result += Double(numbers[i])
  }
  return result
}

It seems as though the optimizer could take advantage of the knowledge of the exact size of the input for making optimization decisions (e.g. loop unwinding).

  1. Does the @specialized attribute require specification of concrete types, or can the specializations use inheritance clauses for constraining types? For example, building on of the examples provided in this proposal would the following be possible:
@specialized(where T: FixedWidthInteger)
func sum<T: BinaryInteger>(_ numbers: T...) -> Double {
  numbers.reduce(0) { $0 + Double($1) }
}

Although this probably isn't a choice example as it doesn't appear that FixedWidthInteger provides any benefit over a plain BinaryInteger in terms of optimization, the question still stands in regards to whether or not this syntax is supported by the attribute.

5 Likes
7

This proposal does not allow this:

The where clause must fully specialize all the generic placeholders of the types in the function signature.

but it is a future direction that we would like to consider.

8

I take it then that "fully specialize" means that concrete types have to be substituted for all generic placeholders?

Another question that came to me after re-reading through the proposal is in regards to the specifics of the internal dispatching mechanism. I see that that's not explicitly laid out how the dispatching will be done and I wanted to inquire about it as I have encountered performance issues around Swift's type casting in my own code (specifically using as? casts) and I'm curious as to how this is planning on being done so as to not negate the performance benefits gained from the specializations?

The latter question doesn't bear any weight in whether or not I feel that this proposal should be accepted, as I do believe that it should, so if this question is better suited for a forum outside of this proposal review I'd be happy to take this specific question somewhere else for additional discussion.

9

This proposal has been accepted.

2 Likes