> What I'm saying here is that even if you accept that the asterisk means all
> platforms, it does not follow that another argument in the same place should
> refer to the platform names *listed in the attribute*. That's not at all
> precedented in the meaning of the asterisk.
The problem is, the most natural way to express this is absolutely this:
@available(OSX 10.8, iOS 8, *) // includes other platforms
@available(OSX 10.8, iOS 8) // excludes other platforms
But we don't want to do that because we want people to use `*` by default. You
could maybe do something like:
@available(OSX 10.8, iOS 8, * unavailable)
But I think that reads very strangely, and it doesn't seem consistent with the
other parameters. (Well, unless you can write `OSX unavailable`, which would
actually be kind of convenient, but would still read oddly in a declaration
named `@available`.) Hence my suggestion:
@available(OSX 10.8, iOS 8, only)
Which is meant to be read as "Available in OS X (starting in 10.8) and iOS
(starting in 8) only".
(It would be nice if the syntax actually said "OSX 10.8+", and maybe even
permitted a range for things that have been retired, like `OSX 10.8..<10.10`.
The main problem I see with supporting a range is that the most natural
interpretation of the right end is an unavailability version, but the most
useful thing to have there would be a deprecation version.)
> Furthermore, the asterisk is put after a list of things *only in the
> shorthand syntax*, whereas you are proposing that "only" should be usable in
> the full syntax as well, in a position where the asterisk is not allowed. It
> is something else entirely to say that a feature is available in OSX version
> so-and-so only and then to say it's available in iOS version so-and-so only,
> when in fact you mean that it's not available *on other platforms*.
Yes, that was not what I intended when I suggested `only`.
> What makes more sense to me would be allowing (if it isn't already allowed)
> `@available(*, unavailable)` to follow a previous @available declaration in
> order to mean that the feature is unavailable on all platforms not otherwise
> specified.
Yes, something like this makes sense to me too. Basically, I think the
shorthand form should look like:
@available(OSX 10.8, iOS 9.4, only)
And the longhand form like:
@available(OSX, introduced: 10.8)
@available(iOS, introduced: 9.4)
@available(*, unavailable)
(The switch from `introduced=` to `introduced:` is an already-approved Swift 3
change.)
Perhaps you should even be required to say either `@available(*)` or
`@available(*, unavailable)` if there are longhand `@available` attributes on
the type.
--
Brent Royal-Gordon
Architechies
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
