Ah, yes. Thanks. On Thu, Sep 22, 2016 at 8:29 PM, Joe Groff <jgr...@apple.com> wrote:
> > > On Sep 22, 2016, at 11:28 AM, Jens Persson <j...@bitcycle.com> wrote: > > > > Yes, but should the compiler silently accept that? And is this issue > really related to the other issue? > > No, this is a separate issue. The compiler might be able to catch some > obvious cases, but it'd be impossible to statically prevent all > circularities. The runtime could probably do a better job detecting this > situation, though, and give a runtime error instead of just letting the > deadlock happen. > > -Joe > > > /Jens > > > > On Thu, Sep 22, 2016 at 8:23 PM, Joe Groff <jgr...@apple.com> wrote: > > > > > On Sep 22, 2016, at 11:23 AM, Jens Persson <j...@bitcycle.com> wrote: > > > > > > Oh, but how can the following (earlier mentioned) example have > anything to do with Script-mode top-level locals being treated as globals? > > > > > > Create "AnotherFile.swift" containing: > > > func f() -> Int { return a } > > > let a = f() > > > > In this case, you have a deadlock, since the initialization of `a` > depends on its own initialization. > > > > -Joe > > > > > Create "main.swift" containing: > > > print(a) > > > > > > Compile. Run. For ever. At zero % CPU. > > > > > > /Jens > > > > > > > > > > > > On Thu, Sep 22, 2016 at 8:03 PM, Jens Persson <j...@bitcycle.com> > wrote: > > > Thank you for the thorough explanation! > > > /Jens > > > > > > On Thu, Sep 22, 2016 at 7:28 PM, Jordan Rose <jordan_r...@apple.com> > wrote: > > > Yep, it really is a long-standing bug. Script-mode top-level locals > are treated as globals (module-scope bindings) by the compiler, but their > initial bindings are evaluated eagerly instead of lazily (as you’d want in > a script). Taken together, this means that you can get this completely > unsafe behavior. > > > > > > So, why is ‘a’ accepted but ‘b’ not in your original example? > > > > > >> func foo() -> Int { return b } > > >> let a = 1 > > >> let b = 2 > > >> print(foo()) > > > > > > The secret to the current behavior is that script mode is executed > interactively, instead of parsing it all up front. To make things a little > better, it actually parses any number of declarations until it sees > something it actually needs to execute—a statement or a declaration with an > initial value expression. This allows for recursive functions while still > being “live”. > > > > > > The consequence here is that one top-level binding after a series of > functions may be visible. This is obviously not optimal. > > > > > > To fix this, we should: > > > > > > - Distinguish between script-mode top-level locals and module-scope > variables that happen to be declared. My personal preference is to treat > anything with explicit access control as a normal lazy global and anything > without access as a top-level local. > > > > > > - Consider parsing everything up front, even if we don’t type-check > it, so that we can say “use of ‘b’ before it’s initialized” instead of > “undeclared name ‘b’” > > > > > > Note that we do need to be conservative here. This code should > continue to be rejected, even though ‘f’ doesn’t refer to ‘local’ directly, > because calling ‘f' would be dangerous before the initialization of ‘local': > > > > > > internal func f() -> Int { > > > return g() > > > } > > > // more code here > > > > > > let local = 42 > > > private func g() -> Int { > > > return local > > > } > > > > > > Thanks for bringing this up, if only so I have an opportunity to write > out the issue. :-) > > > Jordan > > > > > > > > >> On Sep 21, 2016, at 23:04, Jens Persson <j...@bitcycle.com> wrote: > > >> > > >> Did you see the other code examples that came up in that twitter > conversations? > > >> 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 <jgr...@apple.com> wrote: > > >> > > >> > On Sep 21, 2016, at 2:22 PM, Jens Persson via swift-users < > swift-users@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 > > >> > > > > > > > > > > > > > > >
_______________________________________________ swift-users mailing list swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users