User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0)
            Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
References: <jpqrt2$vk7$1@dough.gmane.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Message-ID:  <4FC13326.1060904@morningstar2.co.uk>
Date:         Sat, 26 May 2012 20:46:46 +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: Should l3keys provide a key .initial:n?
To: LATEX-L@listserv.uni-heidelberg.de
In-Reply-To:  <jpqrt2$vk7$1@dough.gmane.org>
Precedence: list
Status: R

On 26/05/2012 16:12, Marco Daniel wrote:
> Hello,
> 
> Today I noticed that there is no key .initial:n. This question popped up
> during writing a small package. Whatever at the moment you have the
> following possibilities to set a key-value-syntax with an initial value:
> =======================================================================
> %First approach:
> 
> \keys_define:nn { module }
>  {
>   myoption .int_set:N  = \l_modul_myoption_int
>  }
> \keys_set:nn  { module }
>  {
>   myoption = 2
>  }
> \ProcessKeysOptions { module }
> 
> =======================================================================
> Second approach
> 
> \keys_define:nn { module }
>  {
>   myoption .int_set:N  = \l_modul_myoption_int ,
>   myoption .default:n  = 2
>  }
> \keys_set:nn  { module } { myoption }
> \ProcessKeysOptions { module }
> 
> =======================================================================

Note that this are not equivalent when you consider the behaviour later
on. In the second case, giving "myoption" is the same as "myoption = 2",
but in the first case the two are distinct.

> I suggest to define a new key .initial:n so that we have a third approach:
> 
> Second approach
> 
> \keys_define:nn { module }
>  {
>   myoption .int_set:N  = \l_modul_myoption_int ,
>   myoption .initial:n  = 2
>  }
> \ProcessKeysOptions { module }
> 
> =======================================================================

At one point we did have this. Checking back through the archive, I
removed it as it did not seem to add anything to the two-stage process.
However, that was not a 'strong' objection: I was simply trying to keep
the number of properties down as far as possible. If this looks like a
useful addition I've no problem adding it back in: anyone else have a view?
--
Joseph Wright