Bruno Le Floch writes:
> >> * These should probably be consistent.
> >> * I think returning a quark is dangerous in case of sloppy package
> >> authors.
> From the seq point of view, I like the idea of \seq_pop:NNF, with a
> \seq_pop:NN variant for an expl3-provided error.
> For prop, a missing key is more often not an error(?), so perhaps
> providing all four \prop_get:NnN(T)(F) variants may make sense. They
> would be implemented internally with a quark test on the result of
> \prop_get:NnN (very small performance overhead). Then
> \prop_if_in:Nn(TF) would be much less useful, since it is just as slow
> as \prop_get:NnN(T)(F).
oh well, all said by Bruno already ...
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
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 find that the quark-based approach is about twice as fast as using
> > \prop_if_in:Nn.
> Yes, you end up doing the same work (defining an auxiliary function,
> expanding the prop, grabbing delimited arguments) twice. And quark
> tests on single tokens are fast.
right, that is one of the reasons why they got invented in the first