Re: [swift-users] Amusing function return warning in swift 3

[Nathan de Vries via swift-users]

I had similar issues with UIApplicationMain when I moved to Swift 3:

 UIApplicationMain's argv parameter should be declared 
nullable

Presumably NSApplicationMain's argv parameter needs the same nullable 
annotation.

—Nathan


> On Jun 12, 2016, at 3:56 PM, Marco S Hyman via swift-users 
>  wrote:
> 
> My first try with 5/31 swift 3 snapshot gave me a warning regarding an unused 
> return value -- in main.swift.   Wouldn’t you know, NS ApplicationMain is 
> declared as
> 
> func NSApplicationMain(_ argc: Int32,
>_ argv: UnsafeMutablePointer?>) -> Int32
> 
> And what does the second line of function help say?
> 
> "This method never returns a result code."
> 
> OK ;)
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

[swift-users] Amusing function return warning in swift 3

[Marco S Hyman via swift-users]

My first try with 5/31 swift 3 snapshot gave me a warning regarding an unused 
return value -- in main.swift.   Wouldn’t you know, NS ApplicationMain is 
declared as

func NSApplicationMain(_ argc: Int32,
_ argv: UnsafeMutablePointer?>) -> Int32

And what does the second line of function help say?

"This method never returns a result code."

OK ;)
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] inout params seem to have undefined behavior

[Brent Royal-Gordon via swift-users]

> Wow there are some real doozy inout code examples in there, showing
> aliasing much more fun than my snippet.  Unfortunately I can't
> understand anything else the doc is talking about.  I guess I'll just
> say a prayer and throw salt over my shoulder if using inout.

Sorry! Here's the money quote from that document:

> # If you didn't catch all that...
> 
> That may have been a somewhat intense description, so here's a simple summary 
> of the rule being proposed.
> 
> If storage is passed to an inout argument, then any other simultaneous 
> attempt to read or write to that storage, including to the storage containing 
> it, will have unspecified behavior. Reads from it may see partially-updated 
> values, or even values which will change as modifications are made to the 
> original storage; and writes may be clobbered or simply disappear.
> 
> But this only applies during the call with the inout argument: the evaluation 
> of other arguments to the call will not be interfered with, and as soon as 
> the call ends, all these modifications will resolve back to a quiescent state.
> 
> And this unspecified behavior has limits. The storage may end up with an 
> unexpected value, with only a subset of the writes made to it, and copies 
> from it may unexpectedly reflect modifications made after they were copied. 
> However, the program will otherwise remain in a consistent and uncorrupted 
> state. This means that execution will be able to continue apace as long as 
> these unexpected values don't trip up some higher-level invariant.

-- 
Brent Royal-Gordon
Architechies

___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] inout params seem to have undefined behavior

[David Sweeris via swift-users]

Oh, ok, I stand corrected. Thanks for the link :-)

Sent from my iPhone

On Jun 11, 2016, at 18:05, Brent Royal-Gordon  wrote:

>> My recollection is that in Swift the subscript operator (`arr[2]` in this 
>> case) can refer to the setter xor the getter, but not both within the same 
>> statement.
> 
> Quite to the contrary. Rather than using the setter directly, Swift often 
> uses `materializeForSet`, a combined get-and-set operation which is much more 
> efficient, particularly when assigning directly into arrays. To keep from 
> having to use very slow access all the time, it imposes a rule (which is not 
> and cannot be enforced by the compiler) that you can't hold two mutable 
> references to overlapping storage simultaneously, or they may do strange 
> things like lose some of the writes you make.
> 
> Here's an old design document discussing some things in this area: 
> 
>  I'm not sure how authoritative it is, but it might give you an idea of 
> what's going on.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users