# Should I specify parameters when renaming a command?

For the sake of having semantic code, I wanted to define a command \closure that has the same effect as \overline. Initially, I thought the simplest way to achieve this would be:

\newcommand{\closure}[1]{\overline{#1}}


But, then I experimented with taking out the use of a parameter in my definition, and I found I could just write:

\newcommand{\closure}{\overline}


Both ways of defining \closure seem to work. So, I have two questions: (a) Is there any difference between the first and second definitions? And, if not, (b) Is one way more "correct" than the other?

• You can simply do \let\closure\overline and then use \closure{...}. What you want to do is just change the name of the macro. And you are always giving an argument. – user11232 Aug 23 '15 at 0:24
• @HarishKumar But that will not check that \closure is not already defined. \newcommand is safer . – cfr Aug 23 '15 at 0:27

## Full form

\newcommand{\closure}[1]{\overline{#1}}


\overline does not like \par. It throws the error:

! Missing \$ inserted.


Therefore, it makes sense to include the restriction to \closure by using non-\long arguments:

\newcommand*{\closure}[1]{\overline{#1}}


Now the error message is:

Runaway argument?
{...
! Paragraph ended before \closure was complete.


Much clearer for the user.

• Definition is easy to understand.
• If the argument must not be \long (no \par tokens allowed), the command should be defined as not \long by the star form of \newcommand. Then the error message is more user-friendly, showing the error for the higher level command.

• Small run-time penalty.

## Without arguments

\newcommand{\closure}{\overline}
\newcommand*{\closure}{\overline}


Star or non-star form does not matter usually, because the macro does not have arguments.

• Efficient.

• Errors are shown for \overline, but the user has used \closure.

## \let form

\let\closure\overline


This can be used, if \overline will not change. Otherwise \closure will hae the meaning of \overline at definition time.

• Most efficient.

• Sometimes \let is not enough. For example, macros with optional arguments or robust macros via \DeclareRobustCommand. Internally these macros define another macro with a small modification of the base name (e.g., name with appended space as part of the name). This is not caught by a simple \let. Package letltxmacro with \LetLtxMacro helps in these cases.
• The underlying command should not change, otherwise the macro defined by \let will still have the old meaning.
• If the command is already defined, \let will overwrite it without warning. This can be fixed by:
\newcommand{\closure}{}% throws an error, if \closure is defined