[Draft] Change @noreturn to unconstructible return type


(Anton Zhilin) #1

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


(TJ Usiyan) #2

I vote for Bottom or Never. None does not convey "this should not occur or
be evaluated".

···

On Sun, Jun 5, 2016 at 2:26 PM, Антон Жилин <swift-evolution@swift.org> 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
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(TJ Usiyan) #3

*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 < swift-evolution@swift.org> 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 < > swift-evolution@swift.org> 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
> 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


(Charlie Monroe) #4

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 <swift-evolution@swift.org> 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
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(L Mihalkovic) #5

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.

This is a language that has put protocol centerstage. It stands to reason express something as essential using a protocol.

protocol Nothing {}

seems more than rational

···

On Jun 5, 2016, at 8:39 PM, Charlie Monroe via swift-evolution <swift-evolution@swift.org> wrote:

On Jun 5, 2016, at 8:26 PM, Антон Жилин via swift-evolution <swift-evolution@swift.org> 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
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


(Pyry Jahkola) #6

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 pick `Never` because `None` would overload the notion of a returnable nothingness with its antonym!

OTOH, "never" is quite unlikely to be a type name in user code, likely pretty googleable, and explains itself quite well in examples like `Result<Value, Never>`.

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.

I think it would be more useful if the compiler allowed `Never` in every type context (i.e. whatever type `T` was expected, an expression of type `Never` would be allowed), making expressions like the following compile:

    let unwrapped: Int = optional ?? fatalError("explanation why this must not happen")

— Pyry

···

On 05 Jun 2016, at 21:26, Антон Жилин via swift-evolution <swift-evolution@swift.org> wrote:


(Anton Zhilin) #7

I have to agree with Never. None is for Optional.none, and it looks like
Void in function signature.
I would argue that Never could not be mistaken as a synonym for Void.

protocol Nothing {}
is exactly how Any could be defined, so it's an opposite entity.
We could define that as a protocol that nothing can confirm to, but
approach with empty enum seems more natural to me, because it does not
require any extra work from the compiler.

- Anton

···

2016-06-05 23:54 GMT+03:00 T.J. Usiyan <griotspeak@gmail.com>:

*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 < > swift-evolution@swift.org> 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 < >> swift-evolution@swift.org> 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
> 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


(Michael Peternell) #8

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 like to call the type `Void`. `Void` is a type with zero possible values. The current `Void` would have to be renamed to `Unit`, the data type with exactly one possible value. Less C, More Haskell :slight_smile: But wait, that's not really Haskell-ish, and it's not C-ish either.

From a typing perspective, it's nice to have a noreturn-function be able to return any type. For example, the Haskell `error` function has type `String -> a`, so you can write

fib :: Integer -> Integer
fib x = error "fib not yet implemented. Sorry"

and it will crash at runtime. Does this make sense for Swift? I don't think so. Swift is not a functional programming language, so I think that @noreturn shouldn't be force-fitted to look like a type. Given that most developers don't really think functionally, but rather imperatively, I don't think it's nice to force them to think functionally if they want to understand why @noreturn has been turned into `None`.

I would prefer the type to be simple, and be implemented as a case-less enum (not a bottom value, as in Haskell).

That's a problem. Because `None`, `Never` or `NoReturn` will be a bottom value in Swift. "Bottom or not" is not a matter of "implementation", it's a conceptual issue. A function returns 'bottom' if and only if it does not return at all: that's the definition of 'bottom'.

func foo() -> NoReturn {
    let x = fatalError("crash please")
    print("1+1=2")
    return x
}

The foo-function above will print "crash please" and crash, "1+1=2" will not be printed, because `fatalError` is a bottom-value. a @noreturn-function by definition returns a bottom value, and bottom shouldn't look like a normal type, and IMHO it shouldn't even have a name. So `@noreturn` looks fine to me.

-Michael

···

Am 05.06.2016 um 20:26 schrieb Антон Жилин via swift-evolution <swift-evolution@swift.org>:


(Brent Royal-Gordon) #9

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 discussed all of these options and more. The issue I see with None is that it could easily be interpreted as Void to those without a C background. (Actually, it's probably the most *natural* name for what we call Void.) `func x() -> None` reads like it returns nothing. `func x() -> Never` reads like it does not return.

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.

Could you elaborate on this? I think it would be really useful to have a bottom type—useful to the point that, within minutes of deciding to think of examples, I quickly came up with some really good ones. Why don't you like having a bottom type?

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.

I'm not sure what you mean by this. There is no "scary bottom thing"; Bottom or None or Never or whatever you call it is still an empty type, and the unwrap still fails because the value is `.none`, not `.some`. The only difference is that you can say something like `let total = basicBooks + fatalError("implement pro books counting")` in an expression and it will compile, since Bottom/None/Never is a subtype of `basicBooks`'s type—it's simply one that will never actually be created.

I wonder if perhaps your experience with Haskell has given you a false impression of how this would work in Swift. Haskell is a pervasively lazy language. Every operation in Haskell is lazy and you have little control over when anything executes. Because of this, `undefined` values can persist for long periods of time and spread deep into your code. But Swift is not pervasively lazy; it is (relatively) simple and obvious to figure out when a given piece of code will run. When you run a Bottom/None/Never-returning expression, it does not return. Period. There is no "it does not return six files away from where you wrote it".

We could prove that it is always true in this case, but compiler must be stupid about this.

Why? The compiler flags an error if it can statically prove a trapping overflow will occur. Why shouldn't it flag an error if it can statically prove a force unwrap will fail?

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.

Well, you can assign the field from a call to something like `fatalError()`, but of course that will crash at runtime. (That's true whether we use a bottom type or an empty type, by the way.)

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.

Again: Why? If one of the associated values is Bottom/None/Never, how is my code improved by the fact that I still need a case for it in a `switch` statement? What's the advantage of not being able to eliminate dead code, or call out code that will inevitably fail? We already want these things for other uses of Bottom/None/Never, like dead code elimination after a precondition fails. Why not here?

···

--
Brent Royal-Gordon
Architechies


(Brent Royal-Gordon) #10

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.

I don't think Nil or Null are good answers here. Whatever their dictionary definitions, they have specific meanings to programmers.

(Actually, I could kind of see *lowercase* `nil`—the nil literal—being an okay option, if only because it would look bizarre. In that case, it would be indicating a lack-of-type. `Nil`, though, looks like it is the type of `nil`, and in many languages it is.)

Or "Nothing" as in Scala.

I think `Nothing` suffers from a slightly less serious case of `None`: it looks like a sensible alternate word for `Void`. If you heard someone say a function "returns nothing", would you think that means it doesn't return, or that it returns but doesn't return any data?

···

--
Brent Royal-Gordon
Architechies


(Brent Royal-Gordon) #11

This is a language that has put protocol centerstage. It stands to reason express something as essential using a protocol.

protocol Nothing {}

seems more than rational

No, this doesn't make sense as a protocol. You should not be able to conform to Nothing, but you could conform to this protocol. You *should* be able to cast anything to Nothing, which this definition doesn't allow. You should be able to call any method, property, or subscript on Nothing* (none of them will actually work), but Nothing has no methods. A `protocol Nothing` is, frankly, the exact *opposite* of what Nothing should be.

* At least notionally. It wouldn't be wrong to omit that as clever, but pointless.

···

--
Brent Royal-Gordon
Architechies


(Charlie Monroe) #12

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 <griotspeak@gmail.com> 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 <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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 <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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
> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(Joe Groff) #13

`Never` seems reasonable to me too. I'll add that to the proposal as an alternative.

-Joe

···

On Jun 5, 2016, at 11:37 AM, T.J. Usiyan via swift-evolution <swift-evolution@swift.org> wrote:

I vote for Bottom or Never. None does not convey "this should not occur or be evaluated".

On Sun, Jun 5, 2016 at 2:26 PM, Антон Жилин <swift-evolution@swift.org> 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
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


(Thorsten Seitz) #14

Ceylon uses `Nothing` for the bottom type.

-Thorsten

···

Am 05.06.2016 um 20:39 schrieb Charlie Monroe via swift-evolution <swift-evolution@swift.org>:

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 <swift-evolution@swift.org> 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
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


(Charles Srstka) #15

I dunno, I think @noreturn is clearer than any of these. It tells you that the function… won’t return. None, Never, etc. could be mistaken as a synonym for Void, whereas @noreturn is pretty hard to miss.

Charles

···

On Jun 5, 2016, at 1:49 PM, Pyry Jahkola via swift-evolution <swift-evolution@swift.org> wrote:

On 05 Jun 2016, at 21:26, Антон Жилин via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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 pick `Never` because `None` would overload the notion of a returnable nothingness with its antonym!

OTOH, "never" is quite unlikely to be a type name in user code, likely pretty googleable, and explains itself quite well in examples like `Result<Value, Never>`.

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.

I think it would be more useful if the compiler allowed `Never` in every type context (i.e. whatever type `T` was expected, an expression of type `Never` would be allowed), making expressions like the following compile:

    let unwrapped: Int = optional ?? fatalError("explanation why this must not happen")

— Pyry


(Charles Srstka) #16

That is the most confusing possible thing that this could possibly be called. Seeing a Void return will cause anyone coming from a C, C++, ObjC, etc. background to think of something that is definitely *not* a no-return function.

Charles

···

On Jun 5, 2016, at 5:41 PM, Michael Peternell via swift-evolution <swift-evolution@swift.org> wrote:

Am 05.06.2016 um 20:26 schrieb Антон Жилин via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>:

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 like to call the type `Void`. `Void` is a type with zero possible values. The current `Void` would have to be renamed to `Unit`, the data type with exactly one possible value. Less C, More Haskell :slight_smile: But wait, that's not really Haskell-ish, and it's not C-ish either.


(Pyry Jahkola) #17

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.

I think it would be more useful if the compiler allowed `Never` in every type context (i.e. whatever type `T` was expected, an expression of type `Never` would be allowed), making expressions like the following compile:

    let unwrapped: Int = optional ?? fatalError("explanation why this must not happen")

— Pyry

I dunno, I think @noreturn is clearer than any of these. It tells you that the function… won’t return. None, Never, etc. could be mistaken as a synonym for Void, whereas @noreturn is pretty hard to miss.

FWIW, in the rejection of SE-0097 <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160530/019879.html>, this was what the core team had to say about it:

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.

— Pyry


(Anton Zhilin) #18

Bringing up an old idea, we could rewrite `rethrows` using Never and throws
type specification:

func call<T, E>(block: () throws E -> T) throws E -> T

But this requires some compiler magic: non-throwing functions should
effectively become functions throwing Never.

- Anton

···

2016-06-06 1:53 GMT+03:00 Charles Srstka <cocoadev@charlessoft.com>:

On Jun 5, 2016, at 5:41 PM, Michael Peternell via swift-evolution < > swift-evolution@swift.org> wrote:

Am 05.06.2016 um 20:26 schrieb Антон Жилин via swift-evolution < > swift-evolution@swift.org>:

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 like to call the type `Void`. `Void` is a type with zero possible
values. The current `Void` would have to be renamed to `Unit`, the data
type with exactly one possible value. Less C, More Haskell :slight_smile: But wait,
that's not really Haskell-ish, and it's not C-ish either.

That is the most confusing possible thing that this could possibly be
called. Seeing a Void return will cause anyone coming from a C, C++, ObjC,
etc. background to think of something that is definitely *not* a no-return
function.

Charles


(David Hart) #19

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 <swift-evolution@swift.org> 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 <griotspeak@gmail.com> 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 <swift-evolution@swift.org> 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 <swift-evolution@swift.org> 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
> 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


(Jacob Bandes-Storch) #20

What about `PreconditionFailure`? If you obtain an instance of this type,
it means a precondition has failed.

Jacob

···

On Mon, Jun 6, 2016 at 9:48 AM, Joe Groff via swift-evolution < swift-evolution@swift.org> wrote:

`Never` seems reasonable to me too. I'll add that to the proposal as an
alternative.

-Joe

> On Jun 5, 2016, at 11:37 AM, T.J. Usiyan via swift-evolution < > swift-evolution@swift.org> wrote:
>
> I vote for Bottom or Never. None does not convey "this should not occur
or be evaluated".
>
> On Sun, Jun 5, 2016 at 2:26 PM, Антон Жилин <swift-evolution@swift.org> > 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
> 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