> * 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
