I'm sorry to have missed the initial review, but this would crash for valid integer literals that are too large to be represented in Int. Is this intentional? If so, shouldn't this API be intValue and the floating-point API doubleValue and not integerValue/floatingValue (the latter implying that any valid integer or floating-point value would be returned)?

According to the Int initializer's documentation, "if the value [that the String parameter] denotes in the given radix is not representable, the result is nil." I confirmed this by running the following code:

  let goodInt = Int("42", radix: 10)
  let badInt = Int("42424242424242424242424242424242424242424242424242424242424242424242424242", radix: 10)
  print("@@@ \(goodInt) @@@ \(badInt) @@@")

The output was:

@@@ Optional(42) @@@ nil @@@

Right, so force unwrapping that value will crash. Is this the intended behavior here for a valid integer literal?

A valid IntegerLiteralExprSyntax would not cause a crash.

The only way a crash would occur, via force unwrap, is if a client called integerValue on an invalid IntegerLiteralExprSyntax. However, there are guardrails in place to prevent clients from creating invalid IntegerLiteralExprSyntaxes. Those guardrails, not initially present in the PR, were the primary focus of feedback.

I might be misunderstanding then. My assumption was that 'IntegerLiteralExprSyntax' can represent any valid integer literal? If so, then calling 'integerValue' on some valid 'IntegerLiteralExprSyntax' values would crash, because not all valid integer literals can be represented as an 'Int'. For example, '42424242424242424242424242424242424242424242424242424242424242424242424242' is a valid integer literal.

IntegerLiteralExprSyntaxes represent Int literals in source files. A non-representable Int won't compile.

This isn't quite accurate; IntegerLiteralExprSyntax is not limited to what can fit into the Int type; it's any sequence of characters that is syntactically a valid integer literal. The error you're showing occurs later on at the semantic analysis phase, but the compiler and SwiftSyntax will still parse it without error. If we try the following command:

echo 'let foo = 42424242424242424242424242424242424242424242424242424242424242424242424242' | \
  swiftc -frontend -emit-syntax -

we'll see this in the output:

...
{
  "id":6,
  "kind":"IntegerLiteralExpr",
    "layout":[{
      "id":5,
      "tokenKind": {
        "kind":"integer_literal",
        "text":"42424242424242424242424242424242424242424242424242424242424242424242424242"
      },

So potentialIntegerValue called on this would return nil, and integerValue would crash.

I agree with @allevato, this "overflows" error is not even coming from typechecking, it's coming from SIL code generation.
Many thanks to @xwu for catching this, I believe we need to make integerValue return an optional.

Right, integer literals are untyped; they are not “Int literals” and can now be arbitrarily large (previously, they were limited to something like 2048 bits).

The same applies for the floating-point types. They should not return rounded Double values if those values cannot represent the literal exactly.

I would recommend renaming them for clarity as well: the literals are called “integer literals” and “float literals,” so these APIs should be called “integerLiteralValue” and “floatLiteralValue.” Ideally, they would be generic over T: ExpressibleByIntegerLiteral and T: ExpressibleByFloatLiteral so users can get the value represented in any type they want.

I now agree with @xwu's concern. Accordingly, I intend to create a story in the bug tracker and raise a follow-up PR.