Second remark, the expression which follows a <i>return</i> instruction in a function
must of course be of the same type as the return type indicated
in the function header.
For example, here, if I have a function <i>f</i> which does not take any arguments
but which returns a <i>double</i>, then
all the <i>return</i> statements in this function must be of type <i>double</i>.
Here, I have an expression which returns <i>b</i>, of type <i>bool</i>. This is incorrect,
and it will generate an error.
Third remark concerning the <i>return</i> statement:
it must of course be the last instruction executed
since the <i>return</i> statement ends the execution of the function.
It makes no sense to put instructions after the <i>return</i> statement.
Let's take, for example, this <i>lire</i> function ["lire" means "read"], which must return
a double after reading it from the standard input.
It begins by displaying a message on the standard output
and then. it declares a variable of type double called <i>n</i> and initializes it
with a value of 0. It reads the value of the double on the standard input
and finally, it returns to the rest of the program the value of <i>n</i>.
After this, the <i>lire</i> function ends.
So there is absolutely no reason to put an instruction after this,
it would be completely wrong.
Fourth and last remark concerning the return statement.
The compiler must always be able to execute a return statement.
Here is the example of the <i>lire</i> function again, written
slightly differently.
We see, again, the request for the user to input a number,
the declaration and initialization of the variable <i>n</i>,
the reading, from the keyboard, of the value of <i>n</i>;
but here, we have a simple test to check if <i>n</i> is strictly positive.
If so, the function will execute the return statement and will thus end
and return the value of <i>n</i>.
But what happens if <i>n</i> is negative?
It is quite possible for <i>n</i> to be negative,
we can absolutely assume that at this point,
the user might have entered a negative value.
In such a case, this test here will be false and so the function will jump to the line after
the <i>if</i> statement and will end up here. And you can see that from
here, there is nothing left to execute. The function will thus end <i>without a return</i>
value. This is impossible,
so the compiler will throw you an error.
The compiler verifies that the function will always end
with a <i>return</i> statement,
which returns a double, here, since it is the function's return type.
In this particular case, what we could have done
would have been to correct the function by adding, for example, a loop here
that would go back to the top of this block as long as, e.g.,
the value of n is negative or zero. Then we would repeat the block
that asks the user for number and assigns it,
which would allow the function to end with a legal value every time.
More specifically,
since we first want to ask the user for a value before testing whether
it is positive or negative,
we obviously need a <i>do while</i> loop.
So, let's write the <i>do while</i> loop here,
with, as condition,
that we ask the question again as long as we get a bad answer.
Originally, we wanted <i>n</i> to be positive
to have a good answer. So we will repeat the loop <i>while</i>,
as long as, <i>n</i> is negative. While it is negative, we must repeat
this loop and as soon as <i>n</i> will have a positive value ,
we will be able to return the value. So we can already write the <i>return</i> statement.
Then, in the loop, we will get the user's input --
first we ask them the question, and then we save their input.
This is what the loop will do.
We write the message here, and we read the value into the variable <i>n</i>.
Now, we still need to declare this variable <i>n</i>
since we use it here as a condition for the <i>while</i> statement
which is outside of the <i>do while</i> loop and since we also use it here for
the return statement; we will declare this variable outside of the block to be able to use it
outside of the block. So we will declare it here, and initialize it with a value
that makes sense, for example, 0.
So, here is the precise form, which corrects the previous mistake.
