It would definitely be more concise, but it's quite a complicated feature unless it's limited to just conforming to a protocol, which would create a weird inconsistency for extension. In your last example, determining what you can usefully do from inside baz() would either require intersecting all the capabilities of TypeA-TypeD or not allow you to use any properties or methods from those types, which really limits how useful this would be.
There have been some threads about partial classes ("extensions with stored properties") in the past - if support for those is added, your concept would be much more powerful, and could act as replacement for inheritance for structs.
But I guess partial classes won't happen until Swift 8 ;-) (if at all)
@jawbroken Thanks for the feedback!
Yeah the thing I mentioned as a side note really isnt too useful after all, after giving it more thought.
I think it would make more sense to just focus on deriving multiple types to a protocol at once.
@Tino Yeah the idea is a little off-center but I got the idea for this from writing extensions in the style that RxSwift does where there is a psuedo namespace trick where extensions are not written directly but in the style of foo.rx.someRxOperator instead of foo.someRxOperator.
This thread came up in a search for something similar. An example that I can think of is what if you have a mixture of SwiftUI and UIKit. Right now I have an extension on Color with a bunch of static properties for all the colors used with the app. When it comes to UIKit they have a UIColor initializer that can take in a Color, but you only get that with iOS 14. It would be nice to make an extension for UIColor and Color with static properties so I don't have to write them twice. I could just use an enum I guess. But that's an example, I guess, where it might be nice to have that option to be able to do extension Color, UIColor { }
Yeah I think being able to extend multiple things in one line would be cleaner in some cases. Currently the best you can do if you need to conform multiple types to a protocol that has a default implementation that is good enough to use as is, is something like this: