Qs about the book : Function Parameters

Re: p.44; explanation directly below the "cargo run" console output
The text in the book at this point is unclear. It loosely references "the pair of curly brackets" where there are in fact 3 of them, one of them, the pair inside the parentheses of the printl! macro wasn't explained so far. And it references "format string" which is unclear what it means and is introduced at this point.
I find it lacks the description what the "another_function(5)" inside the function body of fn main exacly is. It is named a function but not declared; I guess it is a variable at this stage, not?
Meanings, names, terms mix and loose meaning, expressis verbis : would not abstaining from terms as names for variables be a better approach?

Can someone pls explain me what "another_function(5)" inside the function body of fn main exacly is.
And what the format string was?
And why the passing of 5 to "another_function" can occur prior to the declaration of the function "another_function(x: i32) via fn?
And, if parameters are variables, why not
use let x=5?

Thank you :slight_smile:

P.S. I try to learn Rust from the book atm. I have only little coding experience

If asking questions about the book, it might be best to specify the chapter and section title, so that people without physical copies can see what you're referring to.

"The value of x is: {}" is a format string. {} within it is the pair of curly brackets being referred to.

What makes "The value of x is: {}" a format string is the fact that it is being passed to println!. Several different macros accept format strings (such as println!, print!, and format!) and use them to assemble strings from parts.

another_function(5) can be formally called a function call expression. It means: call the function named another_function (which is declared below) and pass 5 to it.

Functions — or more generally, items, of which functions are one kind; roughly anything which can be at the “top level” of a source file — do not behave differently depending on how they are arranged in the file. The compiler looks at all of them at once to understand the program.

Variables do not carry over from one function to another. Every variable within a function must be either declared within the function, or be a parameter. So, if you did write let x = 5; inside fn main(), it would have no effect at all on another_function, regardless of anything else.

This is actually a very important characteristic, in the design of programming languages: it means that in order to understand a function, you only need to look at the function's own code (and the items it refers to), not simultaneously the code of its caller. And you are free to rename any variables, including parameters, inside a function, without affecting how it interacts with the rest of the program. This encapsulation makes it much easier to avoid making mistakes when understanding or improving a program.

2 Likes

I want to encourage you to continue to ask these question.

Because they clearly show that you have not little coding experience but more like almost zero coding experience. Story with tuples, arrays and function are the same in many (most?) other languages.

So we are observing an attempt to learn about how one can write a program from “The Book” without prior coding experience.

And that is, actually, a topic which comes in discussions pretty often, but with no easy answer:
usually people already know some language (often more than one) before they start reading “The Book” thus we have no idea if one can learn to write code in Rust without knowing any other program languages, just from scratch and with help of “The Book”.

4 Likes

To be totally frank, I think you might be getting caught up a bit too much in the semantics of describing parts of a program, to your own detriment. I actually find this part of the book (the part you're asking about) to be very clear and unambiguous (I'm a native English speaker though so your mileage may vary depending on command of the language). I think the plain-language explanation of what's happening here:

fn main() {
    another_function(5);
}

fn another_function(x: i32) {
    println!("The value of x is: {}", x);
}

is that you have a function called main that, when executed, simply calls another function (aptly named another_function) , and passes to it as an argument the integer 5. Upon doing so, another_function is executed. another_function simply prints "The value of x is: 5" to the terminal. The println! macro allows you to inject variables into the string that is ultimately printed. The variable is injected where you have the curly braces.

I wouldn't worry about how to correctly/formally refer to another_function at this point in your learning process. Learning that 5 is an argument and x is a parameter, for example, isn't really going to get you up and running any faster I don't think. I also wouldn't worry about why you can call a function on line 2 that isn't defined until line 5. Just know that you can do it and move on to learning more about the critical building blocks of a Rust program for now.

Rust is a wonderful programming language but it is not an easy one to become productive with. You'll have plenty of time to learn the ins and outs of the language but there are so many complexities that I think you'll get bogged down very quickly if you try to gain a deep understanding of everything as you learn it. Just go through the book, write the code demonstrated, write your own code, experiment, and each time you get a new program compiling/working as desired, you'll be learning and acquiring new tools that will be useful.

1 Like

well its not that easy to understand. As of chapter 3 in the book I am toppled that inside the function body, inside of a pair of curly brackets, there is another pair of curly brackets. I think this is a hack and only working because contained by "".I would have guessed to use parentheses for this.
In the book it is not explained what the string another_function(5) inside the declaration of the function is or is doing or is attempting to do prior to be created by the programmer. There's a transparent machinery at work doing crazy stuff with some parts of the code - it seems to me.
The first sentence of your answer is switching between to call and to name and between to call as in to name and to call as in to invoke...
And what makes my code to be invoked?
And the thing with the sequence of code. Until chapter 3 I learned that it would not make sense to code:
println! x
let x = 3
It would not magically produce 3 on the screen, not?

Until chapter 3 I learned that it would not make sense to code:
println! x
let x = 3
It would not magically produce 3 on the screen, not?

Give it a try! https://play.rust-lang.org/

That's the best way to learn.

2 Likes

It's true that the quote marks are serving an important role. However, in general (and in many programming languages, not just Rust), you will find that all of () {} [] <> are used in many different ways. The fundamental problem here is that there are a limited number of paired bracketing characters that are easy to type on most keyboards, and so languages end up using them for several purposes. As you learn more about Rust and other programming languages, you'll get more accustomed to the common uses of them.

Within a function, there is a definite order in which the code is executed. Outside of functions, “execution” is not a thing that happens to them, and there is no ordering. They are definitions, in the same sense as words would be defined in a dictionary — you don't read the dictionary from beginning to end (unless you're trying to prepare a new edition of the dictionary); you look up the word you need and possibly other words you found in that definition. The Rust compiler reads your entire program, but it doesn't make it be executed in the order it was written — it looks for the function named main() and makes that the starting point of the executable it produces.

5 Likes

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.