An ordered list of parameters is usually included in the definition of a subroutine, so that, each time the subroutine is called, its arguments for that call are evaluated, and the resulting values can be assigned to the corresponding parameters.
Unlike argument in usual mathematical usage, the argument in computer science is the actual input expression passed/supplied to a function, procedure, or routine in the invocation/call statement, whereas the parameter is the variable inside the implementation of the subroutine.
The semantics for how parameters can be declared and how the (value of) arguments are passed to the parameters of subroutines are defined by the evaluation strategy of the language, and the details of how this is represented in any particular computer system depend on the calling convention of that system.
For example, in C, when dealing with threads it is common to pass in an argument of type void* and cast it to an expected type: To better understand the difference, consider the following function written in C: The function Sum has two parameters, named addend1 and addend2.
It adds the values passed into the parameters, and returns the result to the subroutine's caller (using a technique automatically supplied by the C compiler).
At runtime, the values assigned to these variables are passed to the function Sum as arguments.
The values of the arguments are added, and the result is returned to the caller, where it is assigned to the variable sum_value.
Any of these situations causes a mismatch between the parameter and argument lists, and the procedure will often return an unintended answer or generate a runtime error.
Within the Eiffel software development method and language, the terms argument and parameter have distinct uses established by convention.
Some languages use a special keyword (e.g. void) to indicate that the subroutine has no parameters; in formal type theory, such functions take an empty parameter list (whose type is not void, but rather unit).
The exact mechanism for assigning arguments to parameters, called argument passing, depends upon the evaluation strategy used for that parameter (typically call by value), which may be specified using keywords.
Some programming languages such as Ada, C++, Clojure,[citation needed] Common Lisp,[9] Fortran 90,[10] Python, Ruby, Tcl, and Windows PowerShell[citation needed] allow for a default argument to be explicitly or implicitly given in a subroutine's declaration.
Some languages allow subroutines to be defined to accept a variable number of arguments.
The exact requirements and enforcement vary between languages – for example, in Ada 83 output parameters can only be assigned to, not read, even after assignment (this was removed in Ada 95 to remove the need for an auxiliary accumulator variable).
Syntactically, parameter mode is generally indicated with a keyword in the function declaration, such as void f(out int x) in C#.
TScript uses a different approach, where in the function declaration input parameters are listed, then output parameters, separated by a colon (:) and there is no return type to the function itself, as in this function, which computes the size of a text fragment: Parameter modes are a form of denotational semantics, stating the programmer's intent and allowing compilers to catch errors and apply optimizations – they do not necessarily imply operational semantics (how the parameter passing actually occurs).
[16] A syntactically similar construction to output parameters is to assign the return value to a variable with the same name as the function.
This is found in Pascal and Fortran 66 and Fortran 77, as in this Pascal example: This is semantically different in that when called, the function is simply evaluated – it is not passed a variable from the calling scope to store the output in.
An archetypal example is the TryParse method in .NET, especially C#, which parses a string into an integer, returning true on success and false on failure.
Output parameters are often discouraged in modern programming, essentially as being awkward, confusing, and too low-level – commonplace return values are considerably easier to understand and work with.
Thus one must initially declare a variable, and then each step of a chain of functions must be a separate statement.
For example, in Python one might have either: or, more idiomatically: The micro-optimization of not requiring a local variable and copying the return when using output variables can also be applied to conventional functions and return values by sufficiently sophisticated compilers.