FloatingPoint.radix should be transparent.

[stephentyrone]

Not sure why we missed this one, but there it is.

[stephentyrone]

@swift-ci please smoke test

[jrose-apple]

What's the reasoning for making this transparent? (cf. docs/TransparentAttr.rst)

[stephentyrone]

What's the reasoning for making this transparent?

It is occasionally necessary to select between generic algorithms in code that should be compiling down to just a few instructions. Going through a witness table in those cases is catastrophic.

E.g. if we need to rescale a computation to avoid overflow, we want to divide by the radix (which is always exact for large values), not a fixed value (which would introduce an extra rounding for either radix-2 or radix-10 or both).

@inlinable would maybe be acceptable, but none of the downsides to @_transparent are an issue here, and it would be nicer if it is always inlined, even in -Onone, because it's always a known integer constant, so we can benefit from constant propagation and dead-code elimination.

[jrose-apple]

FWIW, _transparent won't actually help you in a generic context, but okay.

[stephentyrone]

FWIW, _transparent won't actually help you in a generic context, but okay.

It will still help when the compiler can specialize a generic function.

E.g.

internal func a<T: FloatingPoint>(_ x: T) -> T {
  if T.radix == 2 {
    // do something with a simpler algorithm
  }
  // do the more complex thing
}

func b(_ x: Float) -> Float {
  return a(x)/2
}

We should be able to specialize and inline a here such that we only end up emitting the code for radix == 2 while maintaining correct behavior of the utility function a for all cases.

[jrose-apple]

Yes, but @inlinable (possibly with @inline(__always)) will do that too.

[stephentyrone]

@inlinable is definitely not sufficient on its own. @inlinable + @inline(__always) may be.

[stephentyrone]

@swift-ci please smoke test