How does that prevent 'a' from being in the scope where 'c' is defined? It is not clear to me what you mean by defining 'c' later. Later where? And how do we ensure that 'a' is not accessible there?
I think lex-lightning's comment has a point. We need to define 'a' and we need to define 'c' and then we need to print 'c' before printing 'a', so although 'c' does not depend on 'a', we still need to keep 'a' in scope because we cannot print it before we print 'c'.
Perhaps a convoluted solution to the problem posed in lex-lightning's comment would be something like this:
#include <stdio.h>
int getint() {
return 42;
}
int main()
{
int a = getint();
int b = getint() + a;
int c;
{
// Shadow 'a' here to make the outer 'a' inaccessible in this scope.
int *a = NULL;
(void) a;
c = getint();
}
int d = b / c;
printf("%d\n", d);
printf("%d\n", c);
printf("%d\n", b);
printf("%d\n", a);
return 0;
}
Output: $ cc -std=c99 -Wall -Wextra -pedantic foo.c && ./a.out
2
42
84
42I’d argue that even declaring ‘c’ is against the spirit though. To say nothing of the eldritch shadow cast there (no disrespect, I think we’re both enjoying playing around here)
Yes, I agree. My code example is meant to show the best we can possibly do to solve the problem in your comment and how contrived that solution is. The fact that this solution is contrived and diverges from the intended spirit of the problem only emphasizes the point of your comment.
That's why I am eager to understand what zelphirkalt really meant when they wrote, "the re-arrangement seems simple: define `c` later". It seems far from simple and, in fact, impossible if we want to avoid contrived solutions.
One note: each variable only gets assigned to once, so FP won’t magic that away.
The side effects might have a different way of management in FP. But the IO will happen in the same order in reality anyway.
So I don’t think there’s a way out, but I honestly would be interested to see it.