Named platforms always take precedence over the *, in essence. Sent from my iPad
> On 27 May 2016, at 15:44, Xiaodi Wu <[email protected]> wrote: > > I dislike `@restricted` for several reasons. First of all, but for a desire > for brevity, @available and @restricted would do the same thing. I don't > think that's justifiable or intuitive. Second, I don't think it's at all > readable: are the named platforms restricted from using the function, or is > the function restricted to those platforms? The name could equally mean > either one. > > Brent's suggestion is perfectly cogent: > > ``` > @available(OSX, introduced: 10.8) > @available(iOS, introduced: 9.4) > @available(*, unavailable) > ``` > > I would even go so far as to say that neither `only` nor `@restricted` are > needed. By that I mean, if you type this: > > ``` > @available(OSX 10.8, iOS 9.4) > ``` > > That's not valid. You'll be prompted to write this: > > ``` > @available(OSX 10.8, iOS 9.4, *) > ``` > > I'd propose to give the user the additional option of writing this: > > ``` > @available(OSX 10.8, iOS 9.4) > @available(*, unavailable) > ``` > > In other words, the rule for using the @available shorthand would be that you > must mention * somewhere; it can be at the end of the shorthand, or it can be > on its own line. This would maintain the desired verbosity so that the latter > option is not as accessible as the preferred one, but it avoids the > recitation of all unavailable platforms currently required. > > >> On Thu, May 26, 2016 at 11:59 PM, Stuart Breckenridge >> <[email protected]> wrote: >> 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
