What the code is supposed to do
The task is to define a function named say_my_name that prints Hey, Andy! whenever it is called. Only the definition is asked for. Nothing calls the function, so a correct answer compiles and prints nothing.
The starting code looks close to right, but it does not compile:
fn say_my_name()
println!("Hey, Andy!");
The compiler reports:
error: expected one of `->`, `where`, or `{`, found `println`
What goes wrong
A person reading the two lines assumes the second belongs to the first. The compiler does not guess. After fn say_my_name() it expects one of three things: a return type introduced by ->, a where clause, or the opening brace { of the body. The next token is println, which is none of these, so it stops and points at it.
The message therefore means: "the header ended, and the body is missing." Two things are wrong at once:
- The function has no body. In Rust, a function body is a block wrapped in curly braces. The header alone is not a complete definition.
- The print statement is outside any function. A
println!call is a statement, and it has to sit inside a function body, where it runs each time the function is called.
Why the braces matter
Every Rust function definition is built from the same parts:
- the keyword
fn; - the name, here
say_my_name; - parentheses for the parameters, empty here;
- an optional return type after
->, left out here; - the body: the statements to run, between
{and}.
The braces are the only thing that marks where the body starts and ends. Rust ignores indentation, so indenting the println! line under the header would make the code look right to a person and change nothing for the compiler.
Fixing it step by step
- Keep the header.
fn say_my_name()is correct: the keyword, the exact name the task asks for, and empty parentheses. - Open the body. Add
{at the end of the header line. - Put the statement inside. The
println!("Hey, Andy!");line goes between the braces, indented by four spaces so readers can see it belongs to the function. - Close the body. Add
}on its own line after the statement. - Don't add a call. The task says to define the function, not to run it.
The fixed code in Rust
fn say_my_name() {
println!("Hey, Andy!");
}
Some details about these three lines:
- The hidden return type. With no
->in the header, the function returns the unit value(), which stands for "nothing useful". Writingfn say_my_name() -> ()means the same thing. println!is a macro. The!marks it as one. It prints its text and then starts a new line. The sibling macroprint!prints without the line break.- The exact text matters. The comma, the space and the exclamation mark in
"Hey, Andy!"are all part of the output. - The semicolon. Statements in Rust end with
;, soprintln!("Hey, Andy!");keeps its semicolon. - Naming. Rust style names functions in snake_case, and the task's name
say_my_namefollows it. Names are case-sensitive, soSay_My_Namewould be a different function.
Defining is not running
Once the definition compiles, nothing has been printed. The body runs only when something calls the function. In a complete Rust program the call goes inside main, where execution starts:
fn say_my_name() {
println!("Hey, Andy!");
}
fn main() {
say_my_name();
say_my_name();
}
This program prints Hey, Andy! twice, once per call. For the lesson, submit the definition alone.
Common mistakes
- Indenting instead of adding braces. The code looks right, but the function still has no body.
- Forgetting the closing brace. The compiler reports an unclosed delimiter.
- Putting the braces in the wrong place. With
fn say_my_name() {}followed by theprintln!line, the function gets an empty body and the statement stays outside any function. The compiler reports an error for that statement. - Changing the name. A different name, such as
sayMyName, declares a different function from the one the task asks for. - Adding a call. Calling the function prints the message, which the task did not ask for.
Checking your fix
Make the change in the editor above and run it. A correct fix compiles with no errors. A complete program that defines this function but never calls it also draws a compiler warning that the function is never used. That warning only says the function has no callers yet, and it does not stop the build.
