Feature Request: Support `InlineArray` type sugar

[kkebo]

Summary

Swift can use experimental type sugar for InlineArray (e.g. [3 x Int]), and swift-syntax already has supported it, but swift-format hasn't supported it yet.

• pitch
• swiftlang/swift: Introduce type sugar for InlineArray swift#80087
• swiftlang/swift-syntax: Parse InlineArray type sugar swift-syntax#3021

Input

test.swift:

let a: [3 x Int] = [1, 2, 3]

Expected result

let a: [3 x Int] = [1, 2, 3]

Actual result

(with --enable-experimental-feature InlineArrayTypeSugar)

let a: [3xInt] = [1, 2, 3]

However, this result causes compiler errrors.

$ swift-format format --enable-experimental-feature InlineArrayTypeSugar -i test.swift
$ swiftc -enable-experimental-feature InlineArrayTypeSugar test.swift
test.swift:1:10: error: 'x' is not a valid digit in integer literal
1 | let a: [3xInt] = [1, 2, 3]
  |          `- error: 'x' is not a valid digit in integer literal
2 | 

test.swift:1:9: error: expected element type
1 | let a: [3xInt] = [1, 2, 3]
  |         `- error: expected element type
2 | 

test.swift:1:9: error: expected ']' in array type
1 | let a: [3xInt] = [1, 2, 3]
  |        |`- error: expected ']' in array type
  |        `- note: to match this opening '['
2 | 

test.swift:1:14: error: consecutive statements on a line must be separated by ';'
1 | let a: [3xInt] = [1, 2, 3]
  |              `- error: consecutive statements on a line must be separated by ';'
2 | 

test.swift:1:14: error: expected expression
1 | let a: [3xInt] = [1, 2, 3]
  |              `- error: expected expression
2 | 

Environment

• swift-format: 58807b9
• swift-syntax: 820501e3cf5894ad1deb8de95649b938a8bbe9f4

[ahoppen]

Synced to Apple’s issue tracker as rdar://148657937

[allevato]

Since the feature is behind an experimental feature flag, you need to pass --enable-experimental-feature InlineArrayTypeSugar to swift-format so that it can pass that down to the parser.

However, we'll still have to add support for InlineArrayTypeSyntax in the pretty printer, since today it will just collapse the tokens together, leaving something that won't round-trip correctly ([3xInt]).

[kkebo]

@allevato Thanks for clarification. I've updated the description.

[allevato]

Given that this syntax has just been pitched and appears to be contentious already, I think it would be premature to add support for it at this time. If the generated node types or their properties change in the future, supporting it in swift-format would add friction to evolving the swift-syntax APIs because they would need to be paired with changes that make swift-format build successfully again.

I think what we do need here is a way to make the pretty printer handle nodes that it doesn't understand more gracefully, by simply preserving whatever whitespace/trivia was present within them. That would resolve a lot of issues when new syntax gets added to the language by not clobbering the code that we don't acknowledge. I'll have to think about how that would work.

[kkebo]

Given that this syntax has just been pitched and appears to be contentious already, I think it would be premature to add support for it at this time.

It makes sense. I totally agree with you.

Should I close this issue? Or should I change the title? I think it would be better to close the issue and create a separate issue for discussion on how to handle nodes that the pretty printer doesn't understand. That's because the description of the issue is misleading.

[allevato]

Let's leave it open to track whatever eventually does happen with the sugar syntax.

I'll open a new issue for the other thing I proposed.