*please* let us not repeat the mostly avoidable challenging-to-explain-to-newcomers-and-vetarans-alike situation that we had in Obj-C with regard to `nil`.
nil Nil NULL NSNull nullptr kCFNull __DARWIN_NULL are the representations of 'don't have' that come to mind. On Sun, Jun 5, 2016 at 2:39 PM, Charlie Monroe via swift-evolution < [email protected]> wrote: > While None is probably the best way to describe the opposite of Any, it > would be often mistaken for .None (i.e. Optional) by newcomers to the > language. > > I'd personally prefer calling it "Nil" (capital N), which really means > "nonexistent". The same way ObjC had "nil" for "id" and "Nil" for Class. > Possibly, to avoid confusion with nil, calling it Null? Though that might > get confused with NSNull, once the NS prefix gets dropped. > > Or "Nothing" as in Scala. > > > On Jun 5, 2016, at 8:26 PM, Антон Жилин via swift-evolution < > [email protected]> wrote: > > > > The following names were suggested: NoReturn, Bottom, None, Never. > > I would pick None, because it looks like opposite to Any and fits nicely > in generic types. > > > > I would prefer the type to be simple, and be implemented as a case-less > enum (not a bottom value, as in Haskell). > > > > None should be a usual enum, with no compiler magic except that > functions returning None are equivalent to current @noreturn. > > > > Example 1. > > let x: None? > > // ... > > let y = x! > > > > It will trap in runtime not because we discover scary bottom thing, as > in Haskell, but because x had value Optional.none at that moment and we > asserted otherwise. > > We could prove that it is always true in this case, but compiler must be > stupid about this. > > > > Example 2. > > Compiler should allow including None in structures. Error will show up > in constructor, when we will not be able to initialize the field. > > > > Example 3. > > None in an enum case makes that case never appear in values of such a > type. But compiler can not know about that. > > > > - Anton > > _______________________________________________ > > 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
