Ah, yes. Thanks.
On Thu, Sep 22, 2016 at 8:29 PM, Joe Groff wrote:
>
> > On Sep 22, 2016, at 11:28 AM, Jens Persson 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 ab
> On Sep 22, 2016, at 11:28 AM, Jens Persson 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
Yes, but should the compiler silently accept that? And is this issue really
related to the other issue?
/Jens
On Thu, Sep 22, 2016 at 8:23 PM, Joe Groff wrote:
>
> > On Sep 22, 2016, at 11:23 AM, Jens Persson wrote:
> >
> > Oh, but how can the following (earlier mentioned) example have anything
> On Sep 22, 2016, at 11:23 AM, Jens Persson 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 c
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()
Create "main.swift" containing:
print(a)
Compile. Run. For ever. At zero % CPU
Thank you for the thorough explanation!
/Jens
On Thu, Sep 22, 2016 at 7:28 PM, Jordan Rose 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
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 b
> On Sep 21, 2016, at 11:04 PM, Jens Persson 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 ex
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 b
> On Sep 21, 2016, at 2:22 PM, Jens Persson via swift-users
> 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 unr
I asked the same question on twitter, and it resulted in some interesting
finds:
https://twitter.com/bitCycle/status/778697998893142016
On Thu, Sep 22, 2016 at 12:41 AM, Zhao Xin wrote:
> I suggest you defining the variables before using them like Marco does.
> Although from the global variable
I suggest you defining the variables before using them like Marco does.
Although from the global variable point of view, both way should be fine.
But the glitch does exist, especially in playground.
Zhaoxin
On Thu, Sep 22, 2016 at 5:59 AM, Marco S Hyman via swift-users <
swift-users@swift.org> wr
> On Sep 21, 2016, at 2:22 PM, Jens Persson via swift-users
> 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 unr
// 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`"
___
swift-users mailing l
14 matches
Mail list logo