Can we use addOptional and addParameter together?

Question

inputParser provides addOptional and addParameter. The doc (https://www.mathworks.com/help/matlab/ref/inputparser-class.html) says

You can define your

Answer 1

The validation function of addOptional is used to determine if the parsed argument corresponds to the parameter specified with addOptional. If the validation function returns false, the current parsed argument is passed to the next addOptional/addParameter

The default validation function of addOptional is a simple ~ischar to distinguish between parameter and value due to performance reasons. See the answer of a TWM employee here. The provided solution however does not cover all use cases.

Below is a solution which works with any datatype, as well as with parameter/value structs. The only caveat: you cannot use a value which is equal to any parameter name.

a = inputParser;

% Validation function needs to check
% - if argument is a parameter name or a value
%   -> any(strcmp(x,a.Parameters))
% - if argument is a parameter/value struct
%   -> isstruct(x) && any(ismember(fieldnames(x),a.Parameters))
addOptional(a,'o','x',@(x)~(any(strcmp(x,a.Parameters)) || isstruct(x) && 
any(ismember(fieldnames(x),a.Parameters))));

addParameter(a, 'p', 1);

%The next three parse commands give all the same result struct

% 'o' as positional parameter
parse(a, 'w', 'p', 2)        

% 'o' as named parameter/value pair
parse(a, 'o', 'w', 'p', 2)   

% parameters provided as param/value struct
pv.o='w';
pv.p=2;
parse(a, pv)

% value of 'o' is a struct
data.x = 1;
parse(a, data)

%You cannot use a value equal to a parameter name
parse(a, 'p', 'p', 2) % FAIL

I suggest you to write a custom function for optional parameters if you don't mind the speed penalty

function addOptionalExt(parserObj,key,default)
parserObj.addOptional(key,default,...
    @(x)~(any(strcmp(x,parserObj.Parameters)) || ...
    isstruct(x) && any(ismember(fieldnames(x),parserObj.Parameters))));

and then use it in your example

a = inputParser;
addOptionalExt(a, 'o', 'x');
addParameter(a, 'p', 1);
parse(a, 'w', 'p', 2)

Answer 2

I do not recommended the use of inputParser with optional arguments that are allowed to be character arrays, because parse() cannot distinguish if the user passes a parameter name (which is always of type char) or the optional input argument. Thus, it is a logical consequence of this behaviour why you cannot pass a char as an optional input argument.

However, if you specify a validation function for the optional input arguments that may be char, you can make it work. From the addOptional documentation under section ‘Tips’:

For optional string inputs, specify a validation function. Without a validation function, the input parser interprets valid string inputs as invalid parameter names and throws an error.

This is the error your example generated.

Fixing your example

'o' is the optional input argument. If you know how to validate the values 'o' needs to accept, provide a validation function that returns true for those valid inputs. For example, if you know 'o' will always be a char array, try the following (line by line).

a = inputParser; 
addOptional(a, 'o', 'default', @ischar);
addParameter(a, 'p', 1);

parse(a, 'x');  % OK

parse(a, 'Hello, World!', 'p', 2);  % OK

parse(a, 'p', 'p', 'p')  % OK, although quite cryptic

parse(a, 3);  % Throws an error, as expected, because 3 is not a char

parse(a, 'p', 4)  % Throws a somewhat unexpected error, because we meant to set parameter 'p' to value 4

The last line seems counter-intuitive, but it's not! We'd expect the parser to detect the parameter 'p' instead of implicitly assuming it is the character we provide for optional argument 'o', which we wanted to omit. It is the expected behaviour, though, as I will explain now.

Why char optionals give inputParser a hard time

The demonstrated bahviour is expected because both the optional and parameter arguments are not required, i.e., optional. If you'd have two optional input arguments, 'o1' and 'o2', their order matters to the input parser (which is why the MATLAB documentation calls them ‘optional positional arguments’). You could never pass a value for 'o2' before a value for 'o1'. This implies 'o2' can only be used if 'o1' is also specified. In other words, 'o1' impedes the use of any other optional arguments.

The same is true for parameters, which should always come after other optional input arguments (as you already quoted). As such, they behave like optionals if any optional input arguments are allowed to be char. The result is MATLAB's inputParser not knowing if a char input is an optional input argument or a parameter. MATLAB's developers have decided to require explicit ordering of optional inputs, so MATLAB can be sure what optional arguments are passed to parse().

Suggested action if optional inputs may be char

Because using optional input arguments requires MATLAB to assume some input arguments referring to an optional input argument, others referring to parameters, this may result in errors, behaviour or results unexpected by the end-user if not all optional arguments are specified.

Input argument schemes are better if written explicitly to prevent this unexpected implicit behaviour. I suggest that if optional input arguments are required that accept char input, you always make them parameters, i.e., name-value pair arguments using addParameter. Using optional input arguments that accept char input only works if not using any parameters, or by explicitly stating (e.g. in the help) that parameter input argument can be used if and only if all optional input arguments are given as well.