> I wonder if \prop_if_in:Nn(TF) isn't expandable (or rather could be made so, > right now it is a protected conditional (for good)). If so then the fact > that it is slower would be ok. I haven't tried, but one could probably build an > expandable if_in as well - whether that's worth the effort is a differnt > matter. 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. 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. > Otherwise, if could be implemented by using internally get > with some internal variable. In the latter cases it would be equally fast > but fairly useless. The only difference being that you don#t have to > unnecessarily specify a variable name you aren't using. I prefer having an expandable test (with the string caveat explained above). Right now, if_in is implemented with prop_split_aux, exactly like prop_get, plus an extra \quark_...:nTF test. Probably slower than using prop_get and \quark_...:NTF. Regards, Bruno % I don't like much the fact that breaks are delimited by \q_stop. % It should be a special \q_break, or not even a quark. % \cs_new_eq:NN \prop_map_break:n \use_i_delimit_by_q_stop:nw \cs_new:Npn \use_ii_i:nn #1 #2 { #2 #1 } \prg_set_conditional:Npnn \prop_if_in:Nn #1 #2 {p,T,F,TF} { \exp_after:wN \use_ii_i:nn \exp_after:wN {\toks_use:N #1} { \prop_if_in_aux:nNwn {#2} } { ? \prop_map_break:n { \prg_return_false: } } \q_prop { } % dummy arguments for the last \prop_if_in_aux:nNwn \q_stop } \cs_new:Npn \prop_if_in_aux:nNwn #1 #2 #3 \q_prop #4 { \use_none:n #2 % most often #2=\q_prop, except the last time \str_if_eq:nnT {#1} {#3} { \prop_map_break:n {\prg_return_true:} } \prop_if_in_aux:nNwn {#1} } % It is possible to use a similar approach (\use_none:n #2 with #2 being % either one token or, at the end, more) to improve \prop_map_function:NN.