How to epxand macro with optional argument equal to (x,y) so that it becomes part of \path(x,y)--(a,b); inside another macro (expansion problem)?

Question

When \myCoordinate accepts MANDATORY argument, following works:

\documentclass{standalone}
\usepackage{tikz}
\newcommand\myCoordinate[1]{#1}
\newcommand\myPath[1][(1,1)]{\path[draw=red]\myCoordinate{#1}--(1,0);}
\begin{document}
\begin{tikzpicture}
\myPath
\end{tikzpicture}
\end{document}

But not when \myCoordinate accepts OPTIONAL argument (replace \myCoordinate and \myPath definitions from above with the following code):

% modify \myCoordinate to accept optional argument and set default value for that argument to (0,0)
\newcommand\myCoordinate[1][(0,0)]{#1}
% replace curly braces (for mandatory argument) with square brackets (for optional argument)
\newcommand\myPath[1][(1,1)]{\path[draw=red]\myCoordinate[#1]--(1,0);}
% you can replace \myPath definition with following one so that optional argument of \myCoordinate reverts to default (but it still doesn't work)
%\newcommand\myPath[1][(1,1)]{\path[draw=red]\myCoordinate--(1,0);}

Judging by the error generated (Giving up on this path. Did you forget a semicolon?), tikz is complaining because something is wrong with expansion of the macro. And that expansion problem is caused by the optional argument of \myCoordinate.

I need \myCoordinate to work while accepting single argument, which is optional argument. I need to make this work with as less complicated code as possible.

On a sidenote, to learn how to send values only to specific optional arguments out of all optional arguments that a command accepts, see this.

Another approach fails alike.

When (instead of having \myCoordinate inside \myPath) \myCoordinate is passed to \myPath as an argument instead, it fails again when the argument of \myCoordinate is optional:

\documentclass{standalone}
\usepackage{tikz}
% following \myCoordinate accepts optional argument and fails when passed as an argument to \myPath
\newcommand\myCoordinate[1][0,0]{#1}
\newcommand\myPath[1][(1,1)]{\path[draw=red]{#1}--(1,0);}
\begin{document}
\begin{tikzpicture}
% neither of the two following lines work when \myCoordinate accepts optional argument
%\myPath[\myCoordinate] % fails
%\myPath[\myCoordinate[(0,0)]] % fails
\end{tikzpicture}
\end{document}

But when definition of \myCoordinate from above and the use of \myPath from above are changed to the following, it works again:

\newcommand\myCoordinate[1]{#1} % works
\myPath % works
%\myPath[\myCoordinate{(0,0)}] % works

So the optional-argument version of \myCoordinate can neither be used directly inside \myPath nor its value can be passed to \myPath as an argument.

My comment on the answer provided by @marmot.

There is considerable downside of passing (pgf) key-value pairs as arguments to a path's style compared to newcommand or NewDocumentCommand (at least in the form showed in your answer, not sure if it can be corrected):

1. too long: compare \myLine[1][north] to \path[myLine={subtract=1,anchor=north}], it's like referring to 3 separate commands at once (\myLine, \subtract, \anchor, or \myLine[\subtract[1]][\anchor[north]])
2. because of this, renaming (if need be) of subtract and/or anchor will require replacement of each subtract and/or anchor occurrence in each myLine style which has parameters passed to it (and there may be tens or hundreds, if not more, in the entire document): compare to renaming \subtract and/or \anchor newcommands which are used ONLY inside \myLine newcommand (in the document preamble)

If possible, solution should be (using value, not key-value, arguments---which relies on position or order of the values passed as arguments, not on their keys) the following: modify tikzset code to replace \path[myLine={subtract=1,anchor=north}] with something like \path[myLine={1,north}] where each of the arguments is optional (meaning that all of the following are valid and work as expected \path[myLine], \path[myLine={1}], and \path[myLine={north}]).

Answer 1

The idea of pgf keys is precisely to avoid all this optional parameters and getting confused by them. Instead of rewriting all your commands and keeping in mind which parameter means what IMHO it is much simpler to use keys. In the example below, if you want to draw the path with all the default options, just do

\path[L];

If you want to subtract 1, have blue instead of red and south instead of north, do

\path[L={subtract=1,anchor=south,color=blue}];

You can reorder the keys as you want,

\draw[L={color=yellow,subtract=0,anchor=south}];

also works. Another advantage of this method is that it is downwards compatible, i.e. if you decide later that you need to add new keys the old commands will still work without the need of loading a new package.

Full example:

\documentclass[tikz,border=3.14mm]{standalone}
\newcounter{myC}
\tikzset{L/.style={/utils/exec=\tikzset{bp/.cd,#1},insert path={[draw=\pgfkeysvalueof{/tikz/bp/color}] 
(\the\numexpr\number\value{myC}-\pgfkeysvalueof{/tikz/bp/subtract}\relax.\pgfkeysvalueof{/tikz/bp/anchor}\space west)
--(\the\numexpr\number\value{myC}-\pgfkeysvalueof{/tikz/bp/subtract}\relax.\pgfkeysvalueof{/tikz/bp/anchor}\space east)}},
bp/.cd,
subtract/.initial=0,
anchor/.initial=north,
color/.initial=red}

\begin{document}
\begin{tikzpicture}[mystep/.code={\stepcounter{myC}}]
   \path node[draw,mystep](1)at (\number\value{myC},0){one};
   \path[L];
   \path node[draw,mystep](2)at (\number\value{myC},0){two};
   \path[L];
   \path[L={subtract=1,anchor=south,color=blue}];
   \draw[L={color=yellow,subtract=0,anchor=south}];
\end{tikzpicture}
\end{document}

The mystep code is copied from Andrew's answer.

ADDENDUM: Reply to the comment in the question on my answer. It is possible to make something like \path[myLine={north,1}]; work using key filters. However, in your case this would require more thoughts simply because a number is also a valid anchor. So how would TikZ know that 1 is not an anchor but the subtract key? (And personally I find it the suggestion not ver well thought, but of course there are well-thought versions of this, e.g. if you say \node[circle,red,... you do not have to say shape=circle,color=red because TikZ will figure this out for you. But in this case there is no ambiguity.)

Answer 2

It is not clear to me what you are trying to do, but I don't think that you need two macros and that this following code might do want you want:

  \documentclass[tikz, border=5mm]{standalone}
  \usepackage{xparse}

  \newcounter{myC}
  \NewDocumentCommand{\myL}{O{north} O{0}}{%
    \def\myC{\the\numexpr(\themyC-#2)}
    \path[draw=red](\myC.#1 west)--(\myC.#1 east);
  }

  \begin{document}
     \begin{tikzpicture}[mystep/.code={\stepcounter{myC}}]
        \path node[draw,mystep](1)at (\themyC,0){one};
        \myL
        \path node[draw,mystep](2)at (\themyC,0){two};
        \myL
      \end{tikzpicture}
  \end{document}

Here is the output:

Note in particular the use of a .code statement to step the counter. I also added some coordinates for placing the nodes in the path statements since otherwise everything is drawn on top of each other.

Answer 3

The way that pgf does parsing of it's arguments relies on an amount of 'look ahead' code, which takes the input and processes it one step at a time in order to extract possible actions. This is based on the idea that only a restricted range of material can appear in arbitrary positions inside a pgf/TikZ statement.

Here, looking for an optional argument involves an assignment (\let) which is not handled by the internals of pgf. At the TeX level, \let is not expandable so the two possible routes pgf has both fail: it's neither a known case nor something that can be expanded. The result would be an infinite loop, except pgf has a loop counter (set at 100 steps initially), which when exhausted leads to an alternative path giving the error.

As such, this is a fundamental limitation/design decision in how TikZ works. Other answers have tackled the problem in alternative ways, but you cannot use a macro with an optional argument here (at leas without trying to re-write significant parts of the TikZ parser).

Commands with only mandatory arguments do not have to have an assignment 'hidden' inside them, which is why they can work here. (Again, one would need to watch entirely arbitrary content.)

Answer 4

The problem is \myN. Using its code directly in \myL will work.

\documentclass{article}
\usepackage{tikz}
\newcounter{myC}

\makeatletter
\newcommand\myN[1][0]{\the\numexpr\themyC-#1\relax}
% square brackets now instead of curly braces
\def\myL{\@ifnextchar[\myL@i{\myL@i[0]}} 
\def\myL@i[#1]{\@ifnextchar[{\myL@ii[#1]}{\myL@ii[#1][north]}}
\def\myL@ii[#1][#2]{\path[draw=red](\the\numexpr\themyC-#1\relax.#2)--(1,0);}
\makeatother

\begin{document}
\begin{tikzpicture}
    \path node[draw,/utils/exec={\stepcounter{myC}}](1){one};
    \myL
    \path node[draw,/utils/exec={\stepcounter{myC}}](2){two};
    \myL[1][west]
\end{tikzpicture}

\end{document}

However, my code is only an example how it works. I have no idea what you really want to achieve ...

Answer 5

When \myCoordinate is used inside \myPath as in your initial code then there is no point in its having the capability to have an optional argument. There is no code path starting from \myPath which does not pass a parameter to the inner \myCoordinate. That is, there is no way to invoke \myPath such that the inner \myCoordinate falls back to its default argument.

Therefore, one option is to have an alternative command for the inner \myCoordinate which doesn't take an optional argument. The user-level \myCoordinate can also use this alternative so there isn't duplication of code.

This would result in code like the following:

\documentclass{standalone}
%\url{https://tex.stackexchange.com/q/490400/86}
\usepackage{tikz}
\newcommand\myCoordinate[1][(0,0)]{\myCoordinateAux{#1}}
\newcommand\myCoordinateAux[1]{#1}
\newcommand\myPath[1][(1,1)]{\path[draw=red]\myCoordinateAux{#1}--(1,0);}
\begin{document}
\begin{tikzpicture}
\myPath
\end{tikzpicture}
\end{document}

You could use the usual \makeatletter ... \makeatother code to make the inner command inaccessible to users.