> On Sep 21, 2016, at 11:04 PM, Jens Persson <[email protected]> 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 <[email protected]> wrote:
>
> > On Sep 21, 2016, at 2:22 PM, Jens Persson via swift-users
> > <[email protected]> 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
>
_______________________________________________
swift-users mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-users
