# Why the free variables in function body don't get bound at function definition time?

**URL:** <https://discourse.julialang.org/t/why-the-free-variables-in-function-body-dont-get-bound-at-function-definition-time/128860>\
**Category:** New to Julia\
**Tags:** offtopic, design\
**Created:** [May 9, 2025, 3:29am UTC](https://discourse.julialang.org/t/why-the-free-variables-in-function-body-dont-get-bound-at-function-definition-time/128860 "2025-05-09T03:29:11Z")\
**Posts on this page:** 1\
**Showing post:** 51

<div class="post-metadata">

**Author:** ![Benny](https://avatars.discourse-cdn.com/v4/letter/b/49beb7/32.png) [@Benny](https://discourse.julialang.org/u/Benny)\
**Post date:** [May 12, 2025, 11:22pm UTC](https://discourse.julialang.org/t/why-the-free-variables-in-function-body-dont-get-bound-at-function-definition-time/128860/51 "2025-05-12T23:22:05Z")

</div>

> [@Leon\_Niceday](#):
>
> That’s reasonable, but then could you move this topic to the Offtopic category?

It doesn’t happen every day, but debating what-ifs or potential v2 behaviors isn’t off-topic. [I’ve debated variable scoping](https://discourse.julialang.org/t/why-not-an-even-harder-scope/50087), never got moved to off-topic. It might be moved to `Internals and Design`, but that’s not necessary either.

> [@Leon\_Niceday](#):
>
> But since you don’t see any usefulness of the concept, seem downright against it, then why do you care how I call it? **.**

To prevent people jumping into the debate with unrelated concepts again, e.g. the confusion over what “transparency” means. Granted, you have a point about programming terminology depending on context, but those contexts are specified and agreed upon, not individually generated. Even disagreements warrant the respect of mutually intelligible discussion.

> [@Leon\_Niceday](#):
>
> > [@](#):
> >
> > You’d lose the ability to redirect `stdout` though.
> 
> How come?

> [@PatrickHaecker](#):
>
> ```julia-auto
> > julia -e 'println(stderr, Base.stdout)'
> Base.TTY(RawFD(17) open, 0 bytes waiting)
> 
> > julia -e 'println(stderr, Base.stdout)' > /dev/null
> IOStream(<fd 16>)
> 
> ```

See how `Base.stdout` (but not `stderr`) is assigned to a different stream depending on how the Julia process is piped in the command line? Let’s put that in practice:

```julia-auto
PS C:\#=not where you want=#> cd #=wherever you want=#
PS C:\#=wherever you want=#> julia -e 'println(""Hello world"")'
Hello world
PS C:\#=wherever you want=#> julia -e 'println(""Hello world"")' > hello.txt

```

(Excuse the double quotes, I’m on Windows and using Powershell.) No printout the second time, but now we have a hello.txt file in the path. If we open it, we find the text `Hello world`. That happened with the exact same `println(x)` code, so we didn’t need (or want to) refactor everything to `println(io, x)` inside explicit file-handling. That’s especially important for code we didn’t write, which often don’t have methods taking an extra `IO` argument (in fact, macro bodies can’t, only generate function calls that can). This is an expected feature of printing in particular.

---

_[View the full topic](https://discourse.julialang.org/t/why-the-free-variables-in-function-body-dont-get-bound-at-function-definition-time/128860)._