wishlist: Way to express `Fn` trait like `(FnOnce() -> !)`

[pnkfelix]

Spawned off of rust-lang/rust#25325

As written by @diwic originally:

Here's a minimal example that shows the problem:

    fn never_return<F: FnOnce() -> !>(f: F) -> ! {
        f();
    }

which fails with:

    error: expected type, found `!`
         fn never_return<F: FnOnce() -> !>(f: F) -> ! {

...AFAICS, there's no good reason this syntax is not allowed.

[reem]

It is possible to fake this using a "void" enum like enum Void { } as the return type and providing an fn unreachable<T>(_: Void) -> T { unsafe { ::std::intrinsics::unreachable() } }, cf. github.com/reem/rust-void for an example.

[sfackler]

You don't need any unsafe code there, fn unreachable<T>(v: Void) -> T { match v {} } will suffice.

[reem]

@sfackler interesting, does that have the same optimization results (i.e. does LLVM know that this unreachable is actually unreachable)?

[sfackler]

Yep: http://is.gd/JVCrHf

enum Void {}

impl Void {
    fn unreachable(&self) -> ! {
        match *self {}
    }
}

O0 IR:

%Void = type {}

; Function Attrs: noreturn uwtable
define internal void @_ZN4Void11unreachable20h428ace37d3624b8ehaaE(%Void* noalias readonly) unnamed_addr #0 {
entry-block:
  %self = alloca %Void*
  store %Void* %0, %Void** %self
  %1 = load %Void** %self, !nonnull !0
  unreachable

join:                                             ; No predecessors!
  unreachable
}

[diwic]

Cool, thanks for bringing it up further.

I'm not familiar with the empty enum type, and I'm quite surprised it's allowed by the Rust language at all. As I understand it, the trick is that it's impossible to create a Void so therefore the closure must panic or loop infinitely - but it's entirely possible to create a Void and have the closure just return that (although it's unsafe):

struct A; let b: Void = unsafe { std::mem::transmute(A) }; b

Also I'm not sure why the unreachable function is needed at all - this works fine too:

enum Void {}

fn never_return<F: FnOnce() -> Void> (f: F) -> ! {
    f();
    unreachable!();
}

[glaebhoerl]

although it's unsafe

For a very good reason.

[pnkfelix]

@diwic writes:

but it's entirely possible to create a Void and have the closure just return that (although it's unsafe):

The fact that such a transmute works today is an implementation artifact that, in an ideal world, would be statically rejected; see also #1076 and rust-lang/rust#4499

In particular, the memory layout for enum without a repr attribute is entirely up to the compiler, and such transmutes risk undefined behavior (UB).

[canndrew]

Relevant: #1001

Is there a reason not to make ! a plain ol' type?

[pnkfelix]

@canndrew I woudn't want ! to be a "plain ol' type".

For example, it does not make sense to use it in many contexts where you should be able to put "normal types", such as argument positions for functions.

As I said on another ticket, if we were to add ! as a type, I would want use of it to require a ?-marker, something like ?Converge. But I am not yet convinced there is sufficient value in re-adding it again.

[glaebhoerl]

it does not make sense to use it in many contexts where you should be able to put "normal types"

Doesn't make sense in what way? Merely not useful to do so, or nonsensical (cannot work) at some deeper level?

if we were to add ! as a type, I would want use of it to require a ?-marker, something like ?Converge.

For what reason? (Sorry, you may have already answered this somewhere - but not on the ticket you linked.)

At a technical level, let me put forth the following proposal as a straw man: (1) ! should be nothing more than special syntax for a particular empty enum type (perhaps defined as a lang item); and (2) there should be an automatic coercion from this type to every type. This at least resolves the "specialness" problem, because (as far as I know) empty enum types can appear anyplace where any other type could appear. The drawback of using one would be that it needs to be eliminated explicitly (with e.g. an unreachable()), which is resolved by adding the coercion. In what way would this not be satisfactory?

[canndrew]

Sure it makes sense. What's wrong with writing

fn id(x: !) -> ! {
    x
}

True, you could never call this function so there's no point in writing it. But it has a meaning so there's no point in disallowing it either. There are times where it would be useful for ! to be a type. Maybe I want to return a Result<T, !> from a function that has to return a Result but which I know can never fail. Or maybe I want Vec<!> for a Vec that's that guaranteed to have no elements. Or maybe I want to write FnOnce() -> ! to refer to the trait of functions that never return.

As I said on another ticket, if we were to add ! as a type, I would want use of it to require a ?-marker, something like ?Converge.

What's the reason for this?

But I am not yet convinced there is sufficient value in re-adding it again.

What's the value in not having it? It just makes the language more complicated. I mean, imagine if we took some other type (eg. ()), gave it some special syntax (let's say #), but arbitrarily decided that it's not "really" a type so you can only use it an few places that you can use any other type, (like here: fn() -> #, but not here: Result<i32, #>). And then we go to the extra effort of specially coding this usage into the compiler. Wouldn't that be insane? That may sound contrived but it's exactly what C does with void.

[canndrew]

Sorry, I hadn't seen @glaebhoerl's very similar comment when I posted mine.

[canndrew]

That may sound contrived but it's exactly what C does with void.

In case it's not obvious what I'm saying here:

Rust fixes C's mistake of not treating empty structs like plain ol' types and instead giving them their own weird syntax and semantics that breaks generic code.

But then rust goes and makes the exact same mistake with empty enums. If we can fix this, we should.

[pnkfelix]

@glaebhoerl wrote:

it does not make sense to use it in many contexts where you should be able to put "normal types"

Doesn't make sense in what way? Merely not useful to do so, or nonsensical (cannot work) at some deeper level?

I will concede that, in theory, many mental models of what "types" denote can be made to work with the !-type. (e.g. in "types-as-propositions", ! classifies a particular set of expressions that definitely diverge; in "types-as-sets-of-values", ! denotes the empty set. Both of these models seem to accommodate the addition fine.)

My problem is that on the implementation side of Rust, I worry about e.g. code-gen for a function that takes an argument of type !.

• Would we actually generate code for such a function? (Would we continue our existing pattern of representing them, like zero-variant enums, by a zero-sized type? Note that I regard that as an anti-pattern...)
• Am I going to end up adding special cases all over the compiler for for this odd new type variant?

From skimming over the PR where this was removed: PR #17603. I would like to infer that the impact on the compiler would be minimal (and thus I would withdraw the above misgivings).

• The problem is that I don't think it is necessarily valid to draw that conclusion -- allowing ! in arbitrary type positions would represent a generalization that may expose problems that were not dealt with at the time prior to PR #17603