Re: [swift-evolution] [swift-evolution-announce] [Rejected] SE-0097: Normalizing naming for "negative" attributes

[Matthew Johnson via swift-evolution]

> On Jun 2, 2016, at 9:52 AM, Sean Heber via swift-evolution 
>  wrote:
> 
> In terms of naming, I almost feel like “None” would be a better name for it 
> as then it reads somewhat as the opposite of “Any” and that has a nice 
> symmetry to me.

+ 1.  Although the inverse of “None” is really “All” (as in “all or none”).  
I’m not necessarily suggesting we use “All”, just pointing out the linguistic 
relationship.  

That said, I do believe we should *consider* alternatives names for “Any” as 
part of the discussion of the name for a bottom type.  It would be nice 
symmetry if we found names for the top and bottom types that are inverses of 
each other.

> 
> l8r
> Sean
> 
> 
>> On Jun 2, 2016, at 4:04 AM, Brent Royal-Gordon via swift-evolution 
>>  wrote:
>> 
>>> 1) For noreturn, the core team prefers to explore a solution where a 
>>> function can be declared as returning an non-constructable “bottom” type 
>>> (e.g. an enum with zero cases).  This would lead to something like:
>>> 
>>> func abort() -> NoReturn { … }
>>> 
>>> This will require some new support in the compiler, but should flow better 
>>> through the type system than @noreturn in function composition and other 
>>> applications.  Joe Groff offered to write a proposal for this.
>> 
>> Are you thinking in terms of a *real* bottom type—that is, a type which is 
>> the subtype of all types—or a fake bottom type which is simply an empty enum?
>> 
>> If you're thinking about a real bottom type, I wouldn't want to call it 
>> `NoReturn`, because the bottom type may end up playing a larger role in the 
>> language. Given our use of `Any`, the natural names for a bottom type are 
>> probably `All` (as the subtype of all types) or `None` (as a type with no 
>> instances). I do worry that those names are a little too short and 
>> attractive, though. `None` might be mistaken for `Void`; `All` might be 
>> mistaken for `Any`, and wouldn't make much sense when read as the return 
>> value of a function.
>> 
>> My best suggestion is `Never`. A function with a `Never` return type would 
>> read as "never returns":
>> 
>>  func abort() -> Never { … }
>> 
>> If it appeared in, say, a generic type, it would mean "never occurs":
>> 
>>  let result: Result
>> 
>> Flowing from that, we can end up with functions taking a `Never` parameter, 
>> which are never called:
>> 
>>  result.flatMapError { (_: Never) in fatalError("can't happen") }
>> 
>> Or `Never?` values, which are never `some`:
>> 
>>  let _: Never? = Result.error
>> 
>> (By the way, the return type of the force unwrap operator on a `Never?` is 
>> `Never`, which is just right: if you force unwrap a `Never?`, it will always 
>> trap, never return.)
>> 
>> The main issue I see with `Never` is that it's an adverb, not a noun. But 
>> the nouns all seem to have problems. And besides, the bottom type isn't so 
>> much a thing as a lack of a thing, isn't it? That's bound to have a slightly 
>> funky name.
>> 
>> -- 
>> Brent Royal-Gordon
>> Architechies
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Rejected] SE-0097: Normalizing naming for "negative" attributes

[Sean Heber via swift-evolution]

In terms of naming, I almost feel like “None” would be a better name for it as 
then it reads somewhat as the opposite of “Any” and that has a nice symmetry to 
me.

l8r
Sean


> On Jun 2, 2016, at 4:04 AM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>> 1) For noreturn, the core team prefers to explore a solution where a 
>> function can be declared as returning an non-constructable “bottom” type 
>> (e.g. an enum with zero cases).  This would lead to something like:
>> 
>>  func abort() -> NoReturn { … }
>> 
>> This will require some new support in the compiler, but should flow better 
>> through the type system than @noreturn in function composition and other 
>> applications.  Joe Groff offered to write a proposal for this.
> 
> Are you thinking in terms of a *real* bottom type—that is, a type which is 
> the subtype of all types—or a fake bottom type which is simply an empty enum?
> 
> If you're thinking about a real bottom type, I wouldn't want to call it 
> `NoReturn`, because the bottom type may end up playing a larger role in the 
> language. Given our use of `Any`, the natural names for a bottom type are 
> probably `All` (as the subtype of all types) or `None` (as a type with no 
> instances). I do worry that those names are a little too short and 
> attractive, though. `None` might be mistaken for `Void`; `All` might be 
> mistaken for `Any`, and wouldn't make much sense when read as the return 
> value of a function.
> 
> My best suggestion is `Never`. A function with a `Never` return type would 
> read as "never returns":
> 
>   func abort() -> Never { … }
> 
> If it appeared in, say, a generic type, it would mean "never occurs":
> 
>   let result: Result
> 
> Flowing from that, we can end up with functions taking a `Never` parameter, 
> which are never called:
> 
>   result.flatMapError { (_: Never) in fatalError("can't happen") }
> 
> Or `Never?` values, which are never `some`:
> 
>   let _: Never? = Result.error
> 
> (By the way, the return type of the force unwrap operator on a `Never?` is 
> `Never`, which is just right: if you force unwrap a `Never?`, it will always 
> trap, never return.)
> 
> The main issue I see with `Never` is that it's an adverb, not a noun. But the 
> nouns all seem to have problems. And besides, the bottom type isn't so much a 
> thing as a lack of a thing, isn't it? That's bound to have a slightly funky 
> name.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution