[swift-evolution] [Proposal] Uniform Initialization Syntax

[Xiaodi Wu]

If `self` is not of type `inout Self?`, then what is the type of `self`
such that you may assign it a value of `nil`?

It certainly cannot be of type `inout Self`, unless `Self` conforms to
`ExpressibleByNilLiteral`, in which case you are able to assign `self =
nil` an unlimited number of times–but that has a totally different meaning.

Could `self` be of type `inout Self!`? Now that implicitly unwrapped
optionals are no longer their own type, I’m not sure that’s possible. But
even if it were, that seems unintuitive and potentially error-prone.

So I think Greg is quite right that, to enable this feature, `self` would
have to be of type `inout Self?`–which is intriguing but potentially more
boilerplatey than the status quo.
On Fri, Jun 9, 2017 at 05:24 Gor Gyolchanyan via swift-evolution <
swift-evolution at swift.org> wrote:

> Good point, but not necessarily.
> Since you cannot access `self` before it being fully initialized and since
> `self` can only be initialized once, this would mean that after `self =
> nil`, you won't be allowed to access `self` in your initializer at
> all.You'll be able to do any potential, cleanup though.
> Also, since there can be only one `self = nil`, there's no reason to treat
> `self` as `inout Self?`, because the only place it can be `nil` is the
> place it cannot be accessed any more.
>
>
> On Jun 9, 2017, at 7:45 AM, Greg Parker <gparker at apple.com> wrote:
>
>
> On Jun 8, 2017, at 5:09 AM, Gor Gyolchanyan via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> 1. Arbitrary `self` Assignments In Intializers
>
> The first ideas is to allow `self = nil` inside failable initializers
> (essentially making `self` look like `inout Self?` instead of `inout Self`
> with magical `return nil`), so that all initializers uniformly can be
> written in `self = ...` form for clarity and convenience purposes. This
> should, theoretically, be nothing but a `defer { return nil }` type of
> rewrite, so I don't see any major difficulties implementing this. This is
> especially useful for failable-initializing enums where the main switch
> simply assigns to self in all cases and the rest of the initializer does
> some post-processing.
>
>
> I don't see how to avoid source incompatibility and uglification of
> failable initializer implementations here. Allowing `self = nil` inside a
> failable initializer would require `self` to be an optional. That in turn
> would require every use of `self` in the initializer to be nil-checked or
> forced. I don't think that loss everywhere outweighs the gain of `self =
> nil` in some places.
>
>
> --
> Greg Parker     gparker at apple.com     Runtime Wrangler
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170609/02c8b314/attachment.html>