* What is your evaluation of the proposal?
I am very much in favor overall, but I do have some minor quibbles.
Firstly, the list of places where you can use autounwrapping is kind of vague:
• property and variable declarations
• initializer declarations
• function and method declarations
• subscript declarations
• parameter declarations (with the exception of vararg parameters)
I assume that the "function and method declarations" and "subscript declarations" entries mean that you can mark their return values as autounwrapped. The separate "parameter declarations" entry means you can also mark initializer, function, method, and subscript parameters as autounwrapped. Is that correct, or do you mean something else?
If so, is the presence or absence of autounwrapping a part of the function's signature? Do closures derived from that function keep the same autounwrapping behavior? Can a closure be explicitly defined to have autounwrapped parameters or return values?
And if so, why aren't you allowed to make a `typealias` for a closure type which has autounwrapped properties or return values? I understand the rule against having a plain type in a `typealias`; many uses won't actually be able to apply the autounwrapping. But the same won't be true for closures.
Secondly, I continue to believe that the notional @_autounwrapped attribute should be an actual, utterable @autounwrapped attribute, for a couple of reasons.
The first reason is for teaching. (I don't do any formal teaching, but I'm sort of the Swift expert in my local circle of programmers, and frequently give demos and explain things to people.) Complicated sugar benefits from having a simpler, clearer desugared form; it makes the various parts of the sugar's semantics much easier to explain. As an example, consider closure syntax. I never use the fully specified syntax for the closure signature before the `in` keyword *except* when teaching. In teaching contexts, though, it's really useful to be able to start with the full syntax and then strip elements of it away to demonstrate how Swift infers things.
Similarly, I think this feature will benefit immensely from allowing you to strip a `T!` declaration down into more atomic parts. The proposal itself itself benefited immensely from giving the semantic the name `@_autounwrapped`; every book, tutorial, and demo on Swift 3+ which takes on the `T!` syntax will similarly benefit from having a name for the thing. Particularly, I think it's valuable to be able to write both the sugared and desugared forms as executable playground code so users can see that they're equivalent.
The second reason I think `@autounwrapped` should be utterable is that I keep noticing places where you don't have an opportunity to change a regular optional to an autounwrapped one. I already discussed this case:
@autounwrapped var y = x
But typealiases are another one:
typealias Delegate = FooDelegate?
@autounwrapped var delegate: Delegate
Admittedly, neither of these is extremely compelling, but we will only find more, and I worry that some of them might be more serious.
* Is the problem being addressed significant enough to warrant a change to Swift?
Yes. ImplicitlyUnwrappedOptional has been a problem from the start. The autounwrapped approach is tremendously more rational.
* Does this proposal fit well with the feel and direction of Swift?
Yes. Swift usually tries to reduce and contain magic; autounwrapped optionals fit those goals a lot better.
* If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
N/A.
* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
Read the proposal, participated pretty heavily in previous discussions.
···
--
Brent Royal-Gordon
Architechies
