Explain how enum variants are also constructors for the enum type

given the following enum

enum Number {
  Int(i32),
  Float(f32)
}

The following expression Number::Int fulfills the FnOnce(i32) -> Number trait.
(same for the Float variant)

Maybe there is a good spot to mention this in the new book?

[cssivision]

I also was confused about this in the book.

[carols10cents]

Is this section in the enum chapter not sufficient?

We can create instances of each of the two variants of IpAddrKind like this:

let four = IpAddrKind::V4;
let six = IpAddrKind::V6;

What I mean is, specifically pointing out, that when one writes only the identifier without the arguments, it is a function.
‎I think that's something worth knowing, for when strange errors come up, mentioning

expected type `FooEnum`, found type `Fn(Baz) -> FooEnum`

Example:

enum Number {
    Integer(i32),
    Real(f32)
}

fn main() {
    let n: Number = Number::Integer; // should be Integer(3)
}

error:

|     let n: Number = Integer; // should be Integer(3)
|                     ^^^^^^^ expected enum `Number`, found fn item
|
= note: expected type `Number`
           found type `fn(i32) -> Number {Number::Integer}`

[steveklabnik]

you can also use it in things like map: ```rust let v = vec![1, 2, 3]; let v = v.into_iter().map(Number::Integer).collect(); ```

Oh, right. I completely forgot where this originated.

[carols10cents]

Yeah, map is the situation in which this is most useful; I do want to point out this idiom in the closures/iterators chapter since it's nice.

It feels weird explaining that enum variants are functions in the closures/iterators chapter, but I also feel like it could be confusing in the enums chapter. In the example of creating the enum instances of IpAddrKind where we say let four = IpAddrKind::V4;, since these variants don't hold any data, we don't put parens after. But even when functions don't have arguments, you still have to have the () when you call the function, and we don't have to say IpAddrKind::V4() to construct a value, so they're not functions exactly.

idk, @steveklabnik, wdyt?

[steveklabnik]

Agree wholeheartedly, basically. I'm conflicted too.

I think it might be okay in the enums chapter...............

[carols10cents]

Unfortunately, the enums chapter is too far along in the print process to make any significant additions. I've tagged this as something to take a look at when we do a third edition, but I'm going to close this for now.

[tmandry]

This question came up today with some people I work with.

Since the online book can updated anytime, can/should this be reopened as a possible addition?

[carols10cents]

We actually ended up working an explanation on this into the Function Pointers section of chapter 19. Reopening this issue to discuss whether this section should be moved to the Enums chapter, referenced from the enums chapter, or something else to make this content easier to find and more useful, but I did want to note that we do cover it in the book now.