Are we back in a position where a different attribute (back to @restricted or similar keyword) would clear up the readability concerns?
The current equivalent in @available terms:
Short form:
@available(OSX 10.8, iOS 8.0, *)
@available(tvOS, unavailable)
@available(watchOS, unavailable)
Long form:
@available(OSX, introduced: 10.8, deprecated: 10.10)
@available(iOS, introduced: 8.0, deprecated: 8.4, obsoleted: 9.0)
@available(tvOS, unavailable)
@available(watchOS, unavailable)
Short form replacement:
@restricted(OSX 10.8, iOS 8.0) // Restricted to OSX, iOS from 10.8 and
8.0, respectively.
Long form replacement:
@restricted(OSX, introduced: 10.8, deprecated: 10.10)
@restricted(iOS, introduced: 8.0, deprecated: 8.4, obsoleted: 9.0)
I would amend the draft proposal: * would not be permitted with @restricted.
The rationale being that if you are restricting to everything, or marking
everything as unavailable, @available(*,unavailable) is a better candidate.
Stuart
> On 27 May 2016, at 11:06, Brent Royal-Gordon <[email protected]> wrote:
>
>> 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
>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
