References: <11lm3sqjz6xux$.dlg@nililand.de>
            <5595661F.1070304@morningstar2.co.uk>
            <CA+jHFwSTVzJ4VYb9tF5n2tgX1hU821hG32_JKQLBfWVZ=SnxTQ@mail.gmail.com> <55962878.5030204@morningstar2.co.uk>
            <bbkmg4gzwky6.dlg@nililand.de>
            <55A4A8D2.6060304@morningstar2.co.uk>
            <1bc6qigbj7juc.dlg@nililand.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101
            Thunderbird/38.0.1
MIME-Version: 1.0
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Message-ID:  <55A4CB65.9050302@morningstar2.co.uk>
Date:         Tue, 14 Jul 2015 09:42:13 +0100
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: Joseph Wright <joseph.wright@MORNINGSTAR2.CO.UK>
Subject: Re: Order of key declarations
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <1bc6qigbj7juc.dlg@nililand.de>
Precedence: list
Envelope-To: <rainer.schoepf@GMX.NET>
Status: R

On 14/07/2015 09:13, Ulrike Fischer wrote:
> Am Tue, 14 Jul 2015 07:14:42 +0100 schrieb Joseph Wright:
> 
>> On 03/07/2015 08:58, Ulrike Fischer wrote:
>>> - .default:X can imho be reset with .default:n= {}.
>>> - .groups:n can imho be reset with  .groups:n = {}.
>>
>> As previously noted, I'll alter this behaviour for .groups:n so a blank
>> version means 'remove from grouping'. I'll also document that.
>>
>> The .default:n is different: an empty default is not the same as no
>> default at all (as a default means effectively a value is always given).
> 
> In many cases it is. E.g. I could see not difference with the
> .code:n or .tl_set:N. And even choice keys works without a default:
> 
> \documentclass{article}
> \usepackage{expl3}
> \begin{document}
> \ExplSyntaxOn
> \keys_define:nn {test}
> { 
> testa .code:n     = {the~argument~is #1!},
> testb .tl_set:N   = \l_test_tl,
> testc .choice:,
> testc /   .code:n={xxx},
> }
> 
> \keys_set:nn {test} {testa,testb,testc}
> 
> \tl_if_empty:NTF\l_test_tl{~empty}{not empty}
> 
> \ExplSyntaxOff
> 
> \end{document} 

I was thinking of

    \keys_define:nn {test}
      {
        testa .code:n = {\tl_show:n {#1}},
        testa .value_required:,
        testb .code:n = {\tl_show:n {#1}},
        testb .value_required:,
        testb .default:n = {}
    }

    \keys_set:nn {test} {testa,testb}

where one might expect to get an error only in the first case. That's
not currently the situation! Setting the value required then setting a
default is a bit odd, but the behaviour should be defined one way or
another. I can see this both ways: I can alter the code so a default
'counts' for a required value or can document that it doesn't.

> But  .default:n={}  wouldn't work with bool. 

No. I could add a property to remove a default but I think at present
it's unusual enough that .undefine: followed by 'recreating' the key
should probably cover it.
--
Joseph Wright