> On Nov 8, 2016, at 1:05 PM, Anton Zhilin <[email protected]> wrote: > > 2016-11-08 23:43 GMT+03:00 Jose Cheyo Jimenez <[email protected]>: > >> Thank for thinking of this. I am not sure on the advantage of having nil as >> a concrete type. >> >> Have you seen this talk? >> >> https://realm.io/news/swift-summit-al-skipp-monads/ >> >> "The concept of “nil” does not exist in Swift (despite the existence of the >> keyword nil!)" >> >> Does that talk change your mind about this pitch? > > Not much. We can talk about Swift literals being untyped as much as we want, > but still all of them, except for nil, have an internal storage type, which > is also picked by default. > Having nil be a concrete type would be extremely confusing to me. I believe currently nil gets stripped out during compilation and it gets replaced with their respective Optional<Type>.none nil is just a convenient way to work with optionals. The same goes to implicit unwrap optionals !
I guess I don't see a reason why nil should be a concrete at all. > For example, integer literals are Builtin.Int2048, if I’m not mistaken. But > we just can’t store nil without creating an instance of a potentially complex > type. > > And this proposal is not about adding nil to all types. You can do this now > with Any, in any case: > > let optionalInt1: Any = 42 > let optionalInt2: Any = () // ewww
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
