> On Jun 6, 2016, at 8:25 AM, David Hart via swift-evolution > <[email protected]> wrote: > > I'm against using Nil as it would have a very different meaning than Nil (or > Null) in all other C-based languages.
Well said :) >> 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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
