It's really weird to read here debates about indistinctness between nil and empty.
nil means not initialized and not needed to use it in current case.empty is empty, initialized empty collection.There are a lot of different cases for both situations.
ps: in case with text field, of course NOT create a label better than allocate and set empty string. Probably here is experts of lazy var everywhere approach.
I'm not arguing that there aren't possible reasonable distinction between "no value" and "empty value". I just think that in many cases, it's completely opaque to the user of an API what the two cases actually mean semantically and it would be better to express the difference more clearly through the type system, e.g. by using an enum. (I actually think the Bool? example is even worse, what does it mean that a method can return true, false or nilâespecially if the method/property is called isSomething or hasSomething)? This doesn't tell me anything, having an enum with three cases would be much clearer.)
I don't know anything about app development, so I might be wrong here, but isn't there a difference between a label and its content? E.g. I would rather write this as
struct Label {
let value: String
}
struct SomeView {
let label: Label?
}
Then you don't need "optional string", just optional label containing string.
It depends on many cases.
For example optional nil is useful for determining initialized call of assign, like isLighting: true (turned on), false(turned off), nil (didn't touched).
In case of strict struct, there is no need an optional data, with complex or additional vars it possible.
struct UserInfo {
let name: String
let summary: String?
}
struct UserView {
let nameLabel: Label
let summaryLabel: Label?
}
Donât forget that iOS/macOS development works with frameworks concieved long before the coming of Swift, so we have to deal with a lot of APIs that could be done much better given Swiftâs expressive type system. In this case, UILabel has a nullable text property and thatâs it.
Right, but the point is that this isn't obvious. I've ran across cases where methods that look like they should return booleans can also return nil (it's even worse in dynamic languages where the type doesn't even help you, and where nil might even evaluate to false) but it's completely unclear why they do so. For somebody writing an API, writing
enum SwitchState {
case turnedOn, turnedOff, notTouched
}
struct Room {
let switchState: SwitchState
}
is much clearer.
Keep in mind though, that I'm not saying you shouldn't use optional booleans or optional collections or anything. You're free to do so. It's just that I personally don't consider them to be valuable enough that I think there should be stdlib support for automatic type coercionsâIMHO, one of the benefits of a static and expressive type system like Swift's is that it allows you to encode a lot of precise semantic information inside your types.
I wasn't aware of that. Would there be a way to create a "stdlib extension for iOS/macOS development" that can include all sorts of helper functions and properties that deal with legacy support but without them "polluting" other code (including app code that is separated from all framework/UI concerns by proper modularisation)?
For me optional is optional with its semantic use.
If we are talking about specific case, where it can be only 2 states and possibility of not initialized, it obvious to deal with Bool.
Enum is bounded collection, but scalable in develop-time, it produces meaning of scalability, when Bool â not.
Isn't it the whole point? Just as presence and present? do not ship with Ruby, but with the Ruby-on-Rails-oriented library ActiveSupport, because web/database apps have to deal with values where the distinction between empty and nil is sometimes pointless, shouldn't Swift equivalent APIs ship with Cocoa?
Yeah, that sounds useful I guess. How does that work exactly? Is there some import Cocoa statement?
Yes, you import Cocoa for a macOS app, import UIKit for iOS apps, etc. Those are managed by Apple, of course.