I use SPM for my regular feature development and usually implement my features under uninhabited enums for parameterized name spaces, and tend to freely define nested types for both ergonomic and semantic benefit.
As a result I get some really gnarly and hard to parse messages in Xcode as it gives me the fully qualified type (e.g. Feature<Param1, Param2, Param3, ParamEtc>.Interface.Data.SomeType.SomeEnum... this could go on — hopefully you get the idea).
Edit: I also wanted to mention this problem is compounded when there's some error involving a couple of said types at a call site.
As Xcode tries to do this for super long types from Combine chains already, I thought it would be great if we could give it hints as to how to make the message legible for any type that we define in Swift. Perhaps we could pass in some options for it to make the AKA automatically or even pass in strings that it would display. What do you all think?
Without seeing your concrete use case, it seems like you might be overdoing it with generics and nesting. There's a healthy amount to both of them but having 5 levels of nesting or 5 generic type arguments seems like too much.
One principle of clean code is that a function should not have too many arguments. The same can be applied to generics. They are also arguments, just at the type system level.
Also, you could try using typealiases to hide complex types and then declare variables with the typealias as the type instead.
Is there a system to when XCode gives you the shortened version of a type signature and when you're stuck with the full version? I've found this an issue with Combine, and even with Collection, where instead of Int you sometimes get a long harangue of collection types ending in .Index.