> On Mar 17, 2016, at 4:18 PM, Chris Willmore via swift-evolution
> <[email protected]> wrote:
>
>> On Mar 17, 2016, at 2:29 PM, Brent Royal-Gordon <[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
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.
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).
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.
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
Otherwise, LGTM!
-Chris_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
