[swift-users] Can anyone please explain this behavior?

[Joe Groff]

> On Sep 21, 2016, at 11:04 PM, Jens Persson <jens at bitcycle.com> wrote:
> 
> Did you see the other code examples that came up in that twitter conversations?

These all look like the same problem. Whatever you're seeing is an accident of undefined behavior due to the hole in our semantic checking.

-Joe

> For example:
> 
> This worrying little program compiles:
> func f() -> Int {
>     return a
> }
> let a = f()
> 
> 
> It also compiles if you print(a) at the end, and it will print 0.
> 
> If we replace Int with [Int] it will still compile but crash when run.
> 
> And also this:
> 
> AnotherFile.swift containing:
> func f() -> Int {
>     return a
> }
> let a = f()
> 
> main.swift containing
> print(a)
> 
> Compile, run (for eternity, at 0% CPU).
> 
> /Jens
> 
> 
> On Thu, Sep 22, 2016 at 3:13 AM, Joe Groff <jgroff at apple.com> wrote:
> 
> > On Sep 21, 2016, at 2:22 PM, Jens Persson via swift-users <swift-users at swift.org> wrote:
> >
> > // This little Swift program compiles (and runs) fine:
> >
> > func foo() -> Int { return a }
> > let a = 1
> > let b = 2
> > print(foo())
> >
> > But if `foo()` returns `b` instead of `a`, I get this compile time error:
> > "Use of unresolved identifier `b`"
> 
> This looks like a bug to me (cc-ing Jordan, who's thought about global scoping issues more than me). In "script mode", it shouldn't be possible to refer to a variable before its initialization is executed. However, the way this is currently modeled is…problematic, to say the least, among other reasons because script globals are still visible to "library" files in the same module.
> 
> -Joe
>