What should be the default and output parameter order in the stored procedure?

I have an old stored procedure called from C# code, I found that it is throwing exceptions similar to what is mentioned in this question.

In my case, I have a default parameter and an output parameter like this:

@ReturnVal BIGINT OUTPUT,
@var       FLOAT = NULL

I am not passing the default parameter from the C# code while calling this stored procedure.

I am able to fix the issue by moving the default parameter after the output parameter, and it's working as expected.

@var       FLOAT = NULL,
@ReturnVal BIGINT OUTPUT

But I would like to know the reason behind it. Is there any standard for passing the parameter order? I have not found any official documentation about it.

Please find below the C# code, I am using Dapper.

string sql = "EXEC [mySP] @ReturnVal OUT";
DynamicParameters dynamicParamaters = new DynamicParameters(new { });
dynamicParamaters.Add(@ReturnVal, null, parameter.DbType, ParameterDirection.Output, 0);
int returnVal = _connection.ExecuteScalar<int>(sql, dynamicParams)

Exception details:

System.Data.SqlClient.SqlException (0x80131904): The formal parameter "@var" was not declared as an OUTPUT parameter, but the actual parameter passed in requested output.
at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection, Action1 wrapCloseInAction) at System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection, Action1 wrapCloseInAction)
at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj, Boolean callerHasConnectionLock, Boolean asyncClose)
at System.Data.SqlClient.TdsParser.TryRun(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj, Boolean& dataReady)
at System.Data.SqlClient.SqlDataReader.TryConsumeMetaData()
at System.Data.SqlClient.SqlDataReader.get_MetaData()
at System.Data.SqlClient.SqlCommand.FinishExecuteReader(SqlDataReader ds, RunBehavior runBehavior, String resetOptionsString, Boolean isInternal, Boolean forDescribeParameterEncryption, Boolean shouldCacheForAlwaysEncrypted)
at System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean async, Int32 timeout, Task& task, Boolean asyncWrite, Boolean inRetry, SqlDataReader ds, Boolean describeParameterEncryptionRequest)
at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method, TaskCompletionSource1 completion, Int32 timeout, Task& task, Boolean& usedCache, Boolean asyncWrite, Boolean inRetry) at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method) at System.Data.SqlClient.SqlCommand.ExecuteScalar() at Dapper.SqlMapper.ExecuteScalarImpl[T](IDbConnection cnn, CommandDefinition& command) at Dapper.SqlMapper.ExecuteScalar[T](IDbConnection cnn, String sql, Object param, IDbTransaction transaction, Nullable1 commandTimeout, Nullable`1 commandType)

Dapper version: 1.50.2

Start with the stored-procedure parameter declarations and the Dapper call shown in the issue, then compare how omitted default parameters and OUTPUT arguments are bound. Use the linked Stack Overflow question and reproduce the exception with Dapper 1.50.2; done means documenting the applicable parameter-order rule or identifying the needed call or declaration change.