[Solved] Book ch07-02: Problem building example with `io::Result<()> `

#1

I am working my way through the book, but I cannot build the example given in listing 7-19. The code that I have is

use std::fmt;
use std::io;

fn function1() -> fmt::Result {
 }

fn function2() -> io::Result<()> {
 }

(I have not copy/pasted from the book, so perhaps I introduced a typo; but I’m trying to work through examples by typing them in myself). That lives in src/lib.rs

The error I get when building is

error[E0308]: mismatched types
 --> src/lib.rs:4:19
  |
4 | fn function1() -> fmt::Result {
  |    ---------      ^^^^^^^^^^^ expected enum `std::result::Result`, found ()
  |    |
  |    this function's body doesn't return
  |
  = note: expected type `std::result::Result<(), std::fmt::Error>`
             found type `()`

error[E0308]: mismatched types
 --> src/lib.rs:7:19
  |
7 | fn function2() -> io::Result<()> {
  |    ---------      ^^^^^^^^^^^^^^ expected enum `std::result::Result`, found ()
  |    |
  |    this function's body doesn't return
  |
  = note: expected type `std::result::Result<(), std::io::Error>`
             found type `()`

My rustc version is rustc 1.33.0 (2aa4c46cf 2019-02-28).

If I’ve posted this in the wrong place or if there is a place where I should have searched for this sort of thing, please let me know and accept my apologies.

0 Likes

#2

What you have isn’t enough to compile yet. An empty block as an expression gives the unit type (), but your functions need to return their respective Result types. You could add just Ok(()) to proceed.

0 Likes

#3

Thank you. That does fix it. And it makes perfect sense. I was defining a function with a return type but not actually returning anything of that type. This is one of those things that is “obvious” once someone else points it out.

But what is displayed (at least in my browser) in the book is in error. I’m not sure where to report that.

1 Like

#4

We’re trying to illustrate how to bring two types with the same name into scope and refer to them, but didn’t really want to get into the implementation of the functions as it’s irrelevant to that point. We didn’t want to imply that functions doing nothing but returning Ok(()) are normal or useful; normally you’d have a more complex implementation in the bodies relevant to your particular task.

Do you have a suggestion on how we could make this less confusing? Comments in the bodies that say “implementation elided” or “snip” or similar?

Also, you can report any issues or suggestions you have with the book in its repo :slight_smile:

1 Like

#5

Introducing the use of unimplemented!() to allow code in progress to compile might be useful here.

0 Likes

#6

Thank you, @carols10cents. I did understand the point that was being illustrated, and I do see that actual working functions are not needed to make that point, but until listing 7-19, everything else that I had tried from listings did compile (well, other than the things with deliberate and well-commented errors).

Furthermore this listing was presented in contrast with something that should produce an error.

If instead we specified use std::fmt::Result and use std::io::Result , we’d have two Result types in the same scope and Rust wouldn’t know which one we meant when we used Result . Try it and see what compiler error you get!

So I am being asked to try the presumably error free code in 7-19 with an alternative to see what errors I do and don’t get in each case.

I will follow up with suggestions in an issue for the book as suggested.

0 Likes

#7

Issue 1882 is now filed.

Note also that what I’ve been referring to here as listing 7-19 on doc.rust-lang.org/book is listing 7-15 in the current master branch.

0 Likes