Implicitly unwrapped optionals are often used when the optional system is a little complicated around one of your variables.
Some of those times are variables that are nil-resettable (where you set nil, and it internally does something to use that as a reset case) or initialisation issues where you can’t know a variable at prior to the initialisation, but can get it out. But these are just two examples. I think trying to work more on tying people’s hands with this attribute specifically designed to handle edge cases seems a little… concerning. It might make more sense to use a computed property covering the internal property completely if you need this behaviour? > On 19 Jul 2017, at 3:31 pm, Glen Huang via swift-evolution > <[email protected]> wrote: > > Anyone has any thoughts on this? > >> On 16 Jul 2017, at 3:46 PM, Glen Huang via swift-evolution >> <[email protected]> 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 >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
