MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
References: <4DA5C4E2.8090005@morningstar2.co.uk>
            <58AFBC3A-4209-4BC0-BB3A-5B14D6B5EFD8@gmail.com>
            <4DA727A9.2050903@morningstar2.co.uk>
            <BANLkTi=gG=oWHUaLyExNwQ6WzghSV6JXyQ@mail.gmail.com>
            <19880.45400.677093.956908@morse.mittelbach-online.de>
            <BANLkTimfOA8TkQdB0uxtcFTbm3EqzHEAFw@mail.gmail.com>
Message-ID:  <19885.65423.941878.710496@morse.mittelbach-online.de>
Date:         Tue, 19 Apr 2011 23:33:03 +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: Frank Mittelbach <frank.mittelbach@LATEX-PROJECT.ORG>
Subject: Re: The nature of popping from an empty sequence
To: LATEX-L@listserv.uni-heidelberg.de
In-Reply-To:  <BANLkTimfOA8TkQdB0uxtcFTbm3EqzHEAFw@mail.gmail.com>
Precedence: list
Status: R

Bruno,

 > See below for an expandable if_in. However, it compares keys with
 > \str_if_eq:nn (to be expandable), so that imposes restrictions on
 > keys.

it would indeed. I wouldn't be so concerned about the fact as such given that
we had a time where we required the keys to be tokens or rather csnames but ...

 > I feel like it is not a huge restriction for practical applications,
 > but I may be wrong. I would say that keys should be stored as is, but
 > compared as strings.

one thing that I would find important is that the behavior is consistent, ie
it wouldn't do if 

\prop_get:NnN followed by \quark_if_no_value:NTF

can return a different result from \prop_if_in:NnTF

that would be counterintuitive I would say

frank