## LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

 Options: Use Forum View Use Monospaced Font Show Text Part by Default Condense Mail Headers Message: [<< First] [< Prev] [Next >] [Last >>] Topic: [<< First] [< Prev] [Next >] [Last >>] Author: [<< First] [< Prev] [Next >] [Last >>]

On 29/09/2014 10:37, Denis Bitouzé wrote:
> Hi,
>
> among others, `.value_forbidden:` and `.value_required:` key properties
> from `l3keys` package are useful: they let us specify that a given key,
> when used, either cannot or must receive a value.
>
> What could be useful as well is a key property, say `.required:`, that would
> specify that the corresponding key /has/ to be used. This could be helpful for
> instance in the case of a document command `\MyModuleSetup` for setting up
> a module `mymodule`:
>
>     \DeclareDocumentCommand \MyModuleSetup { m }
>       { \keys_set:nn { mymodule } { #1 } }
>
> where some module property /has/ to be specified.
>
> I know this can be achieved with something like test of existence of
> some tokenlist and message emitted in case of nonexistence but a high
> level key property for this could be nice.
>
>
> Thanks in anticipation.

Sean has pointed to a similarity to dealing with mandatory arguments at
a design level. This request seems a little different as l3keys isn't
meant to be targeting that area. However, there is clearly overlap.

At present, key properties mainly apply to individual keys in a 'stand
alone' sense. This request is different as it's actually about an entire
set of keys. To me, that seems a bit odd: it's pretty rare that buried
inside a set of optional settings is one or more mandatory ones. There
is also the question of what 'required' might mean, as

key = \empty

or similar might well be equally invalid in the real use case but would
presumably pass such a test.

What I think we need before we can really comment is some solid proposed
use cases, showing why the property is needed as opposed to other
approaches as you outline.
--
Joseph Wright