It bears mentioning that there is an alternative (among other possible ones) which would preserve the ability to use prefix + with StaticBigInt—indeed, all types expressible by integer literals. It would also fix the shortcoming of the initially proposed solution (namely, that StaticBigInt(+42) wasn't supported even though +42 as StaticBigInt was):
extension ExpressibleByIntegerLiteral {
@_alwaysEmitIntoClient @_disfavoredOverload @inline(__always)
public init(_ value: Self) { self = value }
@_alwaysEmitIntoClient @_disfavoredOverload @inline(__always)
public static prefix func + (x: Self) -> Self { x }
}
Pros are that it actually works, has no ABI footprint, and makes this a non-issue not just for StaticBigInt but for all types to come that may step into this problem inadvertently if left to attempt implementing prefix func + for themselves.
Cons are that it vends an extension to ExpressibleByIntegerLiteral (albeit a defensible one in that it is semantically something that all integer literal–expressible types can notionally support) so is a bigger change than originally proposed.
The less elaborate choice of just removing the functionality is entirely fine by me, but it bears clarifying for folks whose takeaway from reading the amendment is that it's an "unfortunate but necessary" decision that there are options.