I'm against using Nil as it would have a very different meaning than Nil (or Null) in all other C-based languages.
> On 06 Jun 2016, at 05:56, Charlie Monroe via swift-evolution > <[email protected]> wrote: > > Adding a Nil *type* is a bit different than casting dozen of identifiers to > (void*)0... > >> On Jun 5, 2016, at 10:54 PM, T.J. Usiyan <[email protected]> wrote: >> >> *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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
