What is the rationale behind defining operators like \coloneq in mathtools.sty using \AtBeginDocument?


What would break if these commands were defined at the end of mathtools.sty? What are the benefits of this detour?

I just noticed that in the document

$a\defeq b$

\defeq stays undefined because of this and that one has to use



  • Well, at the end of the package is not being safe that another package loaded after mathtools will install its own version of \coloneq then. Putting it in \AtBeginDocument is 'safer', unless other packages loaded after mathtools hooks again into \AtBeginDocument, of course – user31729 Jan 19 '17 at 18:47

Like with any use of \AtBeginDocument, it delays execution until after the preamble. The benefit is that one can assess interactions with other packages that were loaded (before or after).

Using \providecommand ensures that if any other package (for whatever reason) creates some macro called \coloneq, it won't redefine it. However, if it doesn't exist, it will define it.

As a package writer, you don't know what other packages will be loaded with yours, and therefore you attempt to accommodate this with delayed definitions (using \AtBeginDocument), using \defs (to overwrite regardless of existence) or conditioning.

  • Thanks for the explanation. The only difference between \AtBeginDocument{\providecommand} and \providecommand seems to be that the commands can be defined elsewhere using \newcommand. However, the packages pxfonts and txfonts define these commands in a way that also works if the commands already exist. So the effort of mathtools isn't really necessary. – gernot Jan 20 '17 at 0:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.