Function with an inout parameter pack - should it compile?

Using Swift
, , , ,
1

I have run into an issue where declaring a function with an inout parameter pack causes the compiler to crash with current versions of Swift, including 5.9, 5.10 and the 6.0 dev branch.

Example:

func foo<each T>(_ t: repeat inout each T) {}

Try it yourself:
https://godbolt.org/z/arzPxzEE5

I would expect the code above to compile. But if it really is the case that inout parameter packs are not yet supported, I would expect an error message informing about the limitation.

The compiler shouldn't crash either way, so I have filed a bug report on the issue:
https://github.com/apple/swift/issues/72209

The question is, should it be possible to define a function with an inout parameter pack or not? An answer and a possible solution would be greatly appreciated.

5 Likes
2

Could someone who worked on the parameter pack proposals etc. pitch in? To fix the compiler crash one would need an answer to this question first.

3

Not an answer, but a data point: I'm sure WritableKeypath works fine in parameter pack (I think WritableKeypath and inout are somehow similar?)

4

Mutation of parameter packs is not supported right now, and that includes inout parameter packs. You're correct that this should be fixed to diagnose instead of crashing though.

1 Like
6

Thanks for the answer! So according to the current language spec, there should be an error message stating something like "Mutation of parameter packs is not supported"?

Would adding support for this feature (inout parameter packs / mutation of parameter packs) require a language evolution proposal? Or could it be implemented more directly? How would one get the ball rolling?

7

I believe the latter, since it feels like there’s really only one way it should work.

If I recall correctly before the SILGen support for pack mutation can be tackled, there are some issues in the parser and type resolution when ownership modifiers annd @autoclosure are combined with repeat in parameter position. Making sure that everything parses to a meaningful AST and adding diagnostics for what’s currently unsupported would be a good starting point.

1 Like
8

Thanks for the swift reply!

I agree. It would make sense for inout to work with parameter packs / variadic generics the same way as it does with standard generics. Upcoming ~Copyable generics and ~Copyable parameter packs should also benefit from inout, borrowing and consuming modifiers already working with Copyable parameter packs.

Ok, that makes sense. I don't have much experience with the Swift codebase (or compilers in general), but I am eager to learn, especially if it helps to get this feature up and running. Being able to use inout parameter packs instead of a trillion overloads for different numbers of generic parameters would be a lifesaver. I am going to take a look at those issues you mentioned and see if I can do something about them. Any help with this endeavor is greatly appreciated.