[swift-evolution] Enforce non-nil assignment to an implicitly unwrapped optional property?
Glen Huang
heyhgl at gmail.com
Wed Jul 19 00:23:12 CDT 2017
Anyone has any thoughts on this?
> On 16 Jul 2017, at 3:46 PM, Glen Huang via swift-evolution <swift-evolution at swift.org> wrote:
>
> I want to define a property for a struct/class that is nil after initialization, but later is guaranteed to have a value after I manually assign to it. I think implicitly unwrapped optional property is designed specifically for that.
>
> However, the problem arises when it comes to how do I enforce that I never mistakenly assign nil to this property?
>
> struct Foo {
> var name: String!
> }
> var foo = Foo()
>
> I can do foo.name = nil and it will compile just fine.
>
> I guess I could do a run-time check with something like:
>
> struct Foo {
> var name: String! {
> willSet {
> if newValue == nil {
> fatalError("nil isn't allowed")
> }
> }
> }
> }
>
> But it feels ugly, and seems to be something checkable at compile time.
>
> I could define a new setter method:
>
> struct Foo {
> private(set) var name: String!
> mutating func setName(_ name: String) {
> self.name = name
> }
> }
>
> But it feel tedious. Enforcing non-nil assignment probably fits 90% of the use cases of IUOs, since that’s basically their definition. Having to deviate from direct assignment syntax in usage and also define a new setter method for the majority cases seems unfortunate.
>
> I wonder if it’s desirable to define an attribute or something to ask the compiler to only allow non-optionals to be assigned to IUO properties?
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
More information about the swift-evolution
mailing list