@zygoloid: Can we not ask for reviewers anymore? (I would have picked you and @jensmaurer, as the main macro-wranglers.)

#3854 didn't move the macro. I thought this patch was suggested/done somewhere else, so I'm pointing this out so no one else loses time hunting it down.

@JohelEGP: That's perfectly fine. I think the point of the present PR is to make it harder to accidentally reintroduce the bad words into the main standard. I'm somewhat sympathetic to that, though it's traded off against splattering even more local macro definitions into the regular text sources, which leaves me in two minds about this. It's a good proof that the "mandates" changes have landed, I suppose.

(I'd also be OK with \renewcommand to something invalid after we're done rather than the Big Braced Block, but either way seems OK.)

I don't like "something invalid"—unless we use \@undefined, which exists for the purpose, but which is @-ful. Another alternative to the BBB is of course \begingroup…\endgroup.

I don't like "something invalid"—unless we use \@undefined, which exists for the purpose, but which is @-ful. Another alternative to the BBB is of course \begingroup…\endgroup.

If we want to be truly Well Behaved, we could define an environment to hold this command. But that really seems like overkill, and I'm OK with the braces as-is.

I would shed no tear if we just lost the braces altogether. The main purpose of this change, as far as I can tell, is to not have the macro available in most of the standard so we don't accidentlaly use it; whether a tiny bit of Annex D gets to see it is largely irrelevant.

The main purpose of this change, as far as I can tell, is to not have the macro available in most of the standard so we don't accidentlaly use it; whether a tiny bit of Annex D gets to see it is largely irrelevant.

I guess I should respond (this time) to clarify the purpose: it's that (not least because the correct \expects renders as another word), and also removing it from macros.tex so that no one thinks it's part of the "standard" set of such macros. As for having the macro stay around, it's slightly unfortunate because it bleeds into other files (but not any that are likely to use it!).

Sure. I'm not really concerned with the public impression we cause with macros.tex. Yes, without braces the macro stays around for files included later, but happily, there isn't much specification content followin Annex D (anymore). So if it avoids trade-offs of unease about arbitrary-seeming braces or groups, I'd simply drop the braces.

Another option would be to drop the grouping and add a \let\requires\relax at the end of the appendix. This would prevent subsequent files from using the now-undefined \requires macro.

That's a good idea. @opensdh: could you use that approach please?

That's a good idea. @opensdh: could you use that approach please?

I assume you mean the \let\requires\relax. That doesn't actually work; it causes LaTeX to ignore the command, not reject it. If we want a "deliberately invalid" definition, presumably \errmessage{Mandating complete} is what we want.

If you want it to show an error instead of silently doing nothing, then you'd use:

\makeatletter
\let\requires\@undefined
\makeatother

@opensdh: ignoring the command seems unconcerning. What's the threat model you're trying to combat here? A DOS attack of \requires macros? All I was thinking we want to avoid is an accidental motion application with the old wording, and if the macro produces no output, that should produce a sufficiently obvious visual defect, don't you think? Of course a build error would be even better, but it feels like a rather minor improvement.

I mentioned both \begingroup and \@undefined already; neither seemed (to me!) an improvement over the braces. I'm not trying to combat any threat, just make it structurally clear how this macro is supposed to be (not) used (and not rely on visual inspection of a very large document).

I'm certain we've already spent more time talking about it than it could ever have saved anyone; sorry that I didn't realize it would attract so much attention.

"Silently do nothing" is at least in principle a problem due to our process of asynchronous pull requests -- there are plenty of merges where no-one looks at the post-merge result and we rely on "build succeeds and check.sh passes" to tell us the document is OK. (Plus there seem to be at least a few edits for motions where there are such obvious visual issues that it's clear the person applying the motion didn't look at the resulting document after application.) I would strongly prefer build errors or check.sh failures for wrong inputs whenever possible.

It would presumably be trivial to check this from check.sh instead if we remain uncomfortable about the macro scope.

Please, no lone braces.

What's the problem with simply defining the \requires only in the appendix? There is no useful use-case lexically following the appendices.

I agree with Jens. In principle it's of course good to prevent misuse as noisily as possible, but practically, there's basically no potential for harm if the macro is defined before its first use (in Annex D) and then just left alive. I'd keep it simple.

Please, no lone braces.

Press reload to see no braces.