Why is there _ExpressibleByBuiltinIntegerLiteral?

Why is there _ExpressibleByBuiltinIntegerLiteral and a ExpressibleByIntegerLiteral?

I'm curious in the technical details, especially since we've had this in Swift as long as I can remember (though I recall it was _BuiltinIntegerConvertible before).

I wonder if in some way this concerns Girard’s paradox?

1 Like

ExpressibleByIntegerLiteral takes the literal as a value of some other integer type. That just raises the question, though, of how we construct that integer type. The compiler could just have builtin knowledge of those types, I suppose, but then it would be hard to do it generically at runtime. Instead, we have this builtin protocol which takes a builtin type that we know how to dynamically construct values from.


Is the limitation of only using builtin Integer types related to compiler optimization? Seems like that would be a reason to block non-builtin implementations from being possible.

It was due to needing access to a type we didn’t want to commit to in the ABI, one with APIs we didn’t want to commit to in the ABI. It’s just a sort of bootstrapping problem, not something deeply significant.

It’s now possible to get equivalent behavior with StaticBigInt. I don’t believe there are any capabilities there reserved to the standard library.

1 Like