> On Mar 17, 2016, at 5:04 PM, Chris Lattner <[email protected]> wrote: > > >> On Mar 17, 2016, at 4:18 PM, Chris Willmore via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >>> On Mar 17, 2016, at 2:29 PM, Brent Royal-Gordon <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>>>> I'm not sure this is a great idea yet. Punishing IUOs with verbose syntax >>>>> may feel good, but runs the danger of making projected Swift interfaces >>>>> from unaudited C and Objective-C APIs too noisy to read. Our current >>>>> syntax was motivated by a strong desire to ensure that Swift interfaces >>>>> remain readable, even for foreign APIs that haven't been annotated with >>>>> Swift interop in mind yet. >>>> >>>> I don’t think that Brent and I are suggesting that attribute syntax for >>>> IUOs should be mandatory or even recommended, merely that it should exist. >>>> That way we can talk about the feature in terms of the underlying >>>> attribute-based representation without it being some hidden, exclusively >>>> compiler-internal thing. >>> >>> That's my position as well. I will probably almost always use the `!` >>> sugar, but when I'm thinking about the feature, and perhaps occasionally >>> when I'm doing something kind of tricky with it, having the desugared >>> Optional + @autounwrap representation may come in handy. >> >> I’ve updated the proposal to more explicitly call out the need for a named >> decl attribute. The name is subject to further discussion, of course: >> >> https://github.com/cwillmor/swift-evolution/blob/9dce2e8d6c1b27f3370e8c2ba8d5b549ab8f6954/proposals/0000-abolish-iuo.md >> >> <https://github.com/cwillmor/swift-evolution/blob/9dce2e8d6c1b27f3370e8c2ba8d5b549ab8f6954/proposals/0000-abolish-iuo.md> > > This is looking great, and I agree that explaining it in terms of an > attribute makes sense. Some more comments: > > "This proposal seeks to remove the ImplicitlyUnwrappedOptional type from the > Swift type system and replace it with an IUO attribute on declarations. > Appending ! to the type of a Swift declaration will give it optional type and > annotate the declaration with an attribute stating that it may be implicitly > unwrapped when used.” > > This is more of a statement of implementation. I would start out with the > first two sentences of your motivation, and then make a more direct statement > about the purpose & payoff, something along the lines of: > > "The ImplicitlyUnwrappedOptional ("IUO") type is a valuable tool for > importing Objective-C APIs where the nullability of a parameter or return > type is unspecified. It also represents a convenient mechanism for working > through definite initialization problems in initializers. > > This proposal aims to make the behavior of these values more simple, local, > and predictable by making any force-unwrap operations happen locally, and > only when necessary for an expression to type check.” > > With this change, your motivation section can be simplified or just merged > into the intro.
My intent when writing the introduction was for it to serve as a summary of the proposal to follow. I feel like writing it like the above would bury the lede (i.e. the IUO type is going away). > This heavily implies a major syntax change, which you aren’t proposing: > > I propose demoting implicitly unwrapped optionals from being a first-class > type in the Swift type system to being an attribute on declarations in Swift. > > How about something like: > > In this proposal, we keep the surface syntax of T! for these types, in the > following locations <the list>. However, internally, the compiler will model > this as a property of the declaration that it is applied to, not as part of > the formal type system. No human would ever write or observe the attribute, > but we will refer to them as @_autounwrapped (properties and parameters) and > @_autounwrappedResult (function and subscript results). The concern about implying a syntax change is valid, and I’ve rewritten this section as a result. I don’t understand why we would propose separate @_autounwrappped and @_autounwrappedResult attributes, though. I figured the semantics of @_autounwrapped would depend on the kind of declaration that it is attached to — if it’s a function-like decl (i.e. function, method, initializer, or subscript), it applies to the result of the decl’s full application; otherwise, to the value of the decl itself. > What is the advantage to allowing someone to write the attribute? > > It is possible to attach @implicitly_unwrapped to a declaration explicitly, > > It seems like this unnecessarily complicates the surface model of Swift. To > me, it seems like there is no advantage to having two ways to spell this. The main thing I had was consistency with other attributes. Are there currently any attributes that can’t be written explicitly like this? I agree that there’s no practical advantage, though. > > Instead of: > The effect of this behavior is that the result of any expression that refers > to an IUO declaration of type T? will either... > > How about: > The effect of this behavior is that the result of any expression that refers > to a value declared as T! will either Yeah, that sounds better. Fixed. New draft: https://github.com/cwillmor/swift-evolution/blob/8f566a63d32dada678c9c0528abc8cbcf936398a/proposals/0000-abolish-iuo.md Diff: https://github.com/cwillmor/swift-evolution/commit/8f566a63d32dada678c9c0528abc8cbcf936398a > Otherwise, LGTM! Thanks! — Chris Willmore
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
