LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Forum View

Use Monospaced Font
Show HTML Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Frank Mittelbach <[log in to unmask]>
Reply To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Date:
Tue, 19 Apr 2011 23:33:03 +0200
Content-Type:
text/plain
Parts/Attachments:
text/plain (24 lines)
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

ATOM RSS1 RSS2