Skip to content

Conversation

@bnbarham
Copy link
Contributor

@bnbarham bnbarham commented Nov 12, 2025

Causes quite a few changes in eg. sourcekit-lsp, so presumably will in other codebases as well. Ideally we'd add this behind some new versioning in the config.

As an example of a change this causes:

private let logMessageToIndexLog:
  @Sendable (
    _ message: String, _ type: WindowMessageType, _ structure: LanguageServerProtocol.StructuredLogKind
  ) -> Void

To:

private let logMessageToIndexLog:
  @Sendable
    (
      _ message: String, _ type: WindowMessageType, _ structure: LanguageServerProtocol.StructuredLogKind
    ) -> Void

Causes quite a few changes in eg. sourcekit-lsp, so presumably will in
other codebases as well. Ideally we'd add this behind some new
versioning in the config.

As an example of a change this causes:
```
private let logMessageToIndexLog:
  @sendable (
    _ message: String, _ type: WindowMessageType, _ structure: LanguageServerProtocol.StructuredLogKind
  ) -> Void
```

To:
```
@sendable
  (
    _ message: String, _ type: WindowMessageType, _ structure: LanguageServerProtocol.StructuredLogKind
  ) -> Void
```
@allevato
Copy link
Member

Is this actually better? In the tests, we've split the function inputs from the function outputs when they were previously together. Instead of:

attributes
(inputs) effects -> outputs

now we have

attributes (inputs)
effects -> outputs

Those tests are cases with extremely narrow widths, but I don't think it's that unlikely that you'd hit it with regular function types in practice.

@bnbarham
Copy link
Contributor Author

Is this actually better?

Arguments both ways I think 😅. This change was mostly a "eh that seems odd" while writing the tests and wasn't really to do with the fix for nonisolated(nonsending). My main concern is how much churn this will cause, which we don't have a great way to address right now.

We also have a group around inputs, so I suspect the above case of:

attributes (
  inputs
) effects -> outputs

Will end up much more common than:

attributes (inputs)
effects -> outputs

@allevato
Copy link
Member

allevato commented Nov 12, 2025

We also have a group around inputs, so I suspect the above case of:

attributes (
  inputs
) effects -> outputs

Will end up much more common than:

attributes (inputs)
effects -> outputs

We might be able to have it both ways: conditionally add the group around the whole baseType only if inputs is an empty tuple?

I guess that doesn't prevent attributes (Int) \n effects -> outputs though 🤔

@bnbarham bnbarham merged commit be60f78 into swiftlang:main Nov 12, 2025
27 of 28 checks passed
@bnbarham bnbarham deleted the revert-type-group branch November 12, 2025 22:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants