The proposed command, "params", would be used like this:

    tag_fnc_someFunction = 
    {
        params [
    		"_position", 
    		["_direction", 0],
    		["_name", ""]
    	];

        // ...
    };

This would be semantically identical to:

    tag_fnc_someFunction = 
    {
    	private ["_position, "_direction", "_name"];

    	_position = _this select 0;
    	_direction = if (count _this >= 2) then { _this select 1 } else { 0 };
    	_name = if (count _this >= 3) then { _this select 2 } else { "" };

    	// ...
    };

It would work by:

• First privatizing any variable names listed in the right hand side ("_position", "_direction", and "_name" in the above example).
• Then assigning the parameters, using the default values for optional arguments.

Calling "params":

• With a non-array _this, or,
• Where _this has too few elements,

Would throw a script error. However, calling it with too many arguments would be permitted, and the additional arguments silently ignored. This would be used for variadic functions.

A binary operator version of "params" would allow a specific array to be specified (on the left hand side) instead of implicitly using "_this", and would be used for extracting sub-arrays in parameters:

    tag_fnc_someFunction = 
    {
        params [
            "_position", 
            ["_direction", 0],
            ["_name", ""]
        ];

        // Extract the x, y, and z from "_position" array:
        _position params ["_x", "_y", "_z"];

        // ...
    };

Or for unpacking arrays in other control structures:

    {
        _x params ["_group", "_index"];

        // ...
    }
    forEach waypoints _someGroup;

The benefits of this command are:

• Increased readability of functions, and increased learnability of SQF.
• Increased performance, particular in comparison to "BIS_fnc_param" (BIS_fnc_param is over 16 times slower than manual argument unpacking, and killzone_kid's experiments indicate "params" could be nearly/over 2 times faster than manual unpacking even just with parameter lists that have no defaults.
• Substantial reductions in the amount of boilerplate argument processing that is found in virtually every function.
• Simplicity of implementation into the engine.