On 30/04/2013 10:42, Lars Hellström wrote:
> IMHO, the notion that "one cannot use \IfNoValueTF at the code level
> because that is a high level command" is utterly bizarre. That many
> low-level features should not be exposed in a high-level context is one
> thing, but also doing the converse is usually a sign that one's design
> is flawed somewhere. When a sensible representation of a fundamental
> concept (missing value, boolean true, boolean false, etc.) can be
> exposed at the high level, then that representation should be used also
> at the low level to the extent possible.
> 
> To me, it is intunitively correct that a \SplitArgument { 2 } { ; } on
> {bar} should yield two NoValues, since clearly two more pieces of data
> were expected but not provided. It also seems that you may want to
> provide some variant of \SplitArgument that supplies default values when
> nothing explicit is given. For \ang{<degree>;<minute>;<second>}, one
> would probably want 0 (i.e., fixed value like for classical \newcommand)
> as default. For \cline{<from>-<to>}, one would probably want the other
> value to be the default (a classical feature of \section and friends).
> So that might be two siblings of \SplitArgument.

Providing optional values is another question: we can tackle that a bit
later (I hope).

On where '-NoValue-' 'lives', the current approach is that it's an
xparse-only concept as it's provided by xparse and so not available if
you use

    \RequirePackage{expl3}

you can't use it.

An alternative view is that it's a more general marker which can then be
defined at the token list level, with a test

    \tl_if_no_value:n(TF)

[or similar: have to watch clash with \quark_if_no_value:n(TF)]. This
test would then be a code level equivalent of \IfNoValue(TF).

This seems to make some sense to me, although I wonder if using
\SplitArgument (design-level) along with a code-level test is 'correct'
in terms of separation of layers.
-- 
Joseph Wright