What is your evaluation of the proposal?
I think the approach here is very sensible.
However, I think the use of
.all will confuse people, it doesn’t suggest that all-other platforms are supported. I haven’t a good solution that isn't an inline closure that you can then add a
switch statement to, here a
default: would be very clear IMO. But I know you guys don’t want to do such things in the manifest format.
As the proposal states,
.all is the same as the
* in eg.
@available(iOS 10, *), but in my experience this is also not well understood. The asterisk implies everything including platforms already specified to not be supported, and that is much like
.all does here.
.all can be
.else(Bool). Where you can specify if you support everything else… or not. Although this would imply you have to specify
.else(false) while with the proposal as it stands not specifying
.all would be enough. Maybe it's not so bad to require
else(Bool) to be specified though. It's explicit.
I understand though that consistency with Swift’s
* may be the priority and that's fine IMO.
Is the problem being addressed significant enough to warrant a change to the Swift Package Manager?
Yes, this is required for a package graph to be resolved that will actually compile.
Does this proposal fit well with the feel and direction of Swift?
It fits well with the Package.swift format.
If you have used other languages, libraries, or package managers with a similar feature, how do you feel that this proposal compares to those?
CocoaPods supports this and it works well, though partly this is also because CocoaPods has a
lint step that verifies the platforms that are declared are actually supported. It's outside the scope here, but a linting step for SwiftPM would be useful to package authors since otherwise this kind of dependency specification is hard to test.
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
I read the proposal twice.