Public no value bool for l3keys

[Skillmon]

This PR will make the \l__keys_no_value_bool public to allow users to directly test for no value without relying on some .default:n trickery (see, e.g., https://tex.stackexchange.com/questions/614690/how-to-distinguish-no-value-from-empty-value-when-setting-l3keys/614719?noredirect=1#comment1535606_614719 for a possible use case).

[FrankMittelbach]

Just a thought without thinking it through, but shouldn't we first take a look at the broader picture and perhaps marry that with the xparse mechanism to be uniform (and allowing people to query using \IfNoValueTF and the like as well)? I see the two getting closer over time with xparse allowing key/value arguments and then it would be rather awkward if two totally different interface deal with the same kind of question, i.e. was a value given.

[josephwright]

On the specifics of the keys case: the fact that one can't tell if a key has no value or an empty value was by-design. My model was that keys are essentially properties and therefore each key always has some 'value' even if it's empty: there's no such thing as a 'key with no value'. That's of course doable at a lower level but then one is constructing different types of keyval interface.

[Skillmon]

But isn't the level of xparse and l3keys totally different (at least at the moment)? xparse is to create a document interface possibly using only 2e-interfaces, l3keys is to create code (currently without a 2e-interface). The \IfNoValueTF route was what Phelype and I used in the TeX.SX thread, but it feels kind of clunky to use .default:n "just" for this, and changing the notion that a value is by default empty if no value was given seems like a big change prone to introduce regressions somewhere. This PR wouldn't change anything of the established behaviour, just make something public which is internally used anyways.

[FrankMittelbach]

But isn't the level of xparse and l3keys totally different (at least at the moment)? xparse is to create a document interface possibly using only 2e-interfaces, l3keys is to create code (currently without a 2e-interface).

yes it is, as you say "at the moment". All I was saying that I expect that to change because we will need to identify on the xparse level that an argument is a key/val argument and deal with it without forcing the user to do expl3 programming (or not in common cases). Just like xparse took away the need to do low-level 2e programming to get optional arguments or starred forms.

I'm not saying that right now it is clear what that would mean and how one would best interface with it but I would think a 2e like interface to some aspects of l3keys that is integrated with ltcmd is needed. This remark was not about the pull specifically only that when starting to augment it is something to keep in mind or consider broadly.

[Skillmon]

Also, what's the problem with using an interface now that already is there, and later add another interface that is possibly accessible from 2e? No matter what the future of l3keys will be, the handling via \keyval_parse:nnn is unlikely to be removed, and setting the boolean there is (comparatively) a small overhead, even if later it is decided to handle keys without a value differently.

[car222222]

I strongly suspect that it is uncommon for the state of being “unassigned” (i.e. with no value set) to be described as (or to be equivalent to the state of) being “empty” (for either a key-value key (as here) or for a more general property).

@josephwright wrote:
"My model was that keys are essentially properties and therefore each key always has some 'value' even if it's empty: there's no such thing as a 'key with no value'."

Also, in this context, “having the value ‘empty’” can mean many things. I quote:

But what do we mean here by the phrase ‘having the value
(named) “empty” ’ ?
Maybe one of these two? :

• its value is “the empty string” ;
• its value is the token list that contains no tokens.

Or maybe something else is meant by this value called “empty”?
Such as “nothing” or “void” or even “NoValue”.

Or do we mean that the key itself “is empty” (has the property of “being empty”) in some other sense, rather than that the term “empty” refers to the value of the key?