While \pgfpatharc doesn't use \pgf@yc (at least not until it has already been evaluated and stored somewhere else) and it would have been safe to do
\pgfpatharc{90}{-90}{\pgf@yc}
(without the \the even), the manual itself warns
Attention: PGF uses these registers to perform path operations.
For reasons of efficiency, path commands do not always guard them.
As a consequence, the code
\pgfpointadd{\pgfpoint{\pgf@xa}{\pgf@ya}}{\pgfpoint{\pgf@xb}{\pgf@yb}}
may fail:
Inside \pgfpointadd, the \pgf@xa and friend registers might be modified.
In particular, it might happen that \pgf@xb is changed before \pgfpoint{\pgf@xb}{\pgf@yb} is evaluated.
The right thing to do would be to first expand everything using \edef and process the values afterwards, resulting in unnecessary expensive operations.
Of course, one can avoid this by simply looking into the source code of \pgfpointadd to see which registers are used.
(Interestingly enough, the given example would actually work but not
\pgfpointadd{\pgfpoint{\pgf@xb}{\pgf@yb}}{\pgfpoint{\pgf@xa}{\pgf@ya}}
because the coordinates of the first point will be stores in \pgf@xa and \pgf@ya to be later added to those of the second point.)
In the case of \pgfpatharc, #3 get evaluated before \pgf@yc gets used and this only happens scoped, so \pgf@yc still has the same value after \pgfpatharc.
So, yes, the developer of the circuits library could have taken a look into the defintion of \pgfpatharc and could have determined that there's no point.
But there are other points to be considered:
- The
\pgfpatharc command might have worked differently at the time of writing the circuits library.
- The
\pgfpatharc command might change in the future.
- The author of the circuits library at some other point noticed a conflict and changed all similar macro calls so that they never have to deal with such problems again.
\pgfpatharcneeds\pgf@ycto work and would overwrite its original value. – cjorssen Oct 16 '22 at 16:02\pgfpatharcused\pgf@ycor not. It's quite possible that they encountered a case where not expanding prior to the function call proved catastrophic and so they decided to expand in every case just to be on the safe side. – Andrew Stacey Oct 16 '22 at 16:08