References: <m3k34m4vjd.fsf@somewhere.org>
            <5429D0DF.7060608@morningstar2.co.uk> <m3k34lrqkb.fsf@example.com>
            <10k836fpz0maa.dlg@nililand.de>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Message-ID:  <m3lhozrgp6.fsf@example.com>
Date:         Wed, 1 Oct 2014 16:46:13 +0200
Reply-To: Mailing list for the LaTeX3 project
              <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
Sender: Mailing list for the LaTeX3 project <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
From: =?utf-8?Q?Denis_Bitouz=C3=A9?=
              <denis.bitouze@LMPA.UNIV-LITTORAL.FR>
Subject: Re: [l3keys] Suggestion: Add a key property for specifying key that /has/ to be used
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <10k836fpz0maa.dlg@nililand.de> (Ulrike Fischer's message of
              "Wed, 1 Oct 2014 15:18:57 +0200")
Precedence: list
Envelope-To: <rainer.schoepf@GMX.NET>
Content-Transfer-Encoding: 8bit
Status: R

Le 01/10/14 à 15h18, Ulrike Fischer
<news3-x73OiligfUT+tKtrA809HA@public.gmane.org> a écrit :

> Am Tue, 30 Sep 2014 19:00:52 +0200 schrieb
> denis.bitouze-/xtQRdnxTdLaUcvLomQ+0NOM1ZH/LfCJ@public.gmane.org:
>
>> In the use case I have in mind, `key' would be required and expect an
>> integer. Would it be missing, an error message would be emitted; would
>> its value be anything but an integer, an(other) error message would be
>> emitted.
>
> It is normally not the *key* that is required but a *value*

Except if some keys are considered as mandatory arguments (and they
could not be turned into arguments because keys are much more explicit
than arguments).

> and there is no one-to-one relation between keys and values: e.g. in
> geometry you can set the left margins through the keys hmargin,
> margin, implicitly when you set other width etc.

Indeed.

> So a key property .required would be senseful only for "basic keys"
> and you would have to be very careful that you use these basic key
> if you set the value with other keys too.

Indeed but I guess I wouldn't be bitten by this in my real usecase.

> Imho it is easier and more logical to test for the value and emit an
> error if is doesn't exist.

OK but, AFAICS, there isn't any high level key property for this (and
that's the point of this thread): `.value_required:' tests for the value
only if the corresponding key is used. This is pointed out by the
following MWE (that outlines my real usecase as detailed yesterday): the
`month' key property has the `.value_required:' property but nothing
happens if it isn't used.

--8<---------------cut here---------------start------------->8---
\documentclass{article}
\usepackage{xparse}
\ExplSyntaxOn

\int_new:N \l_issue_number_int
\int_new:N \l_issue_month_int
\int_new:N \l_issue_year_int

\keys_define:nn { journal/issuesetup }
{
  number .int_set:N = \l_issue_number_int,
  month .int_set:N = \l_issue_month_int,
  year .int_set:N = \l_issue_year_int,
  number .value_required:,
  month .value_required:,
  year .value_required:,
}

\NewDocumentCommand{\issuesetup}{ m } {
  \keys_set:nn { journal/issuesetup } { #1 }
  The~issue's~number~is:~\int_use:N \l_issue_number_int
}

\ExplSyntaxOff
\begin{document}
\issuesetup{number=154}
\end{document}
--8<---------------cut here---------------end--------------->8---

> (Actually I wouldn't emit an error. As almost everyone is using
> scrollmode today error message are often ignored.

Most of the TeX editors highlight errors, no? At least it is the case
for TeXstudio, for instance.

>  I would give the issue number a default value of
> a {\Huge\color{red}XXXXXXX})

I could provide both of them: belt /and/ suspenders! :)
-- 
Denis