>
> My migration guide landed on swift.org today! I think it will be a big
> help.
> https://swift.org/migration-guide/se-0107-migrate.html
>
> -Andy
>
Thanks Andy, this is great!
I hope that over time, even more accessible material is added for
newcomers. I still feel I would have a hard time
Thank you for all your replies, Shawn.
Zhaoxin
On Thu, Sep 8, 2016 at 12:22 PM, Shawn Erickson wrote:
> You are implementing function defined in the WCSessionDelegate so that
> your AppDelegate can be called by WCSession as things happen. It calls your
> implementation and
Oh I also meant to state that original version of this visitor was marked
as @noescape since it doesn't in the implementation. It looks like I have
lost that ability with the @escaping change since appears to assume it is
escaping in this situation now?
-Shawn
On Wed, Sep 7, 2016 at 9:16 PM
I also have a question on this API
`func session(_ session: WCSession, activationDidCompleteWith
activationState: WCSessionActivationState, error: Error?)`. Why did it use
`throws`? The other APIs, which use NSError in Objective-C, change to
throws in Swift counterpart.
Zhaoxin
On Thu, Sep 8,
For one RealmSwift should likely consider changing their enum cases to use
lowerCamelCase like Swift 3 did. Also at some point it should consider the
changes to NSError / Swift.Error bridging.
-Shawn
On Wed, Sep 7, 2016 at 7:18 PM Zhao Xin via swift-users <
swift-users@swift.org> wrote:
> When
When I use RealmSwift in my project, I got an alert " 'Error' is ambiguous
for type lookup in this context".
import UIKit
import UserNotifications
import WatchConnectivity
import RealmSwift
extension AppDelegate:WCSessionDelegate {
func session(_ session: WCSession,
It just seems a little strange that @escaping only shows up once in the
following example (real) function of mine yet both of them are escaping.
This fixit message should maybe imply that @escaping isn't needed since the
optional one is already implicitly considered escaping? ...it is kinda
On Wed, Sep 7, 2016 at 5:54 PM, Michael Ilseman via swift-users <
swift-users@swift.org> wrote:
> I implemented a better (i.e. correct) diagnostic message for this at
> https://github.com/apple/swift/pull/4670. I want to also do a better
> diagnostic specifically for aggregate parameters to
I implemented a better (i.e. correct) diagnostic message for this at
https://github.com/apple/swift/pull/4670. I want to also do a better diagnostic
specifically for aggregate parameters to functions (e.g. optional closures),
but that requires more work in the type checker.
Basically,
--
Sent from Gmail Mobile
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
I see https://bugs.swift.org/browse/SR-2324 and
https://bugs.swift.org/browse/SR-2444 which looks related to this issue and
may explain the error I saw on "the other side" of this.
On Wed, Sep 7, 2016 at 3:28 PM Shawn Erickson wrote:
> Yeah I actually have a few of those
Yeah I actually have a few of those myself that I can no longer do.
On Wed, Sep 7, 2016 at 3:26 PM Jon Shier wrote:
> Perhaps relatedly, it no longer seems possible to mark typealiased
> closures as @escaping. That was quite handy when you know that closures
> will always be
Perhaps relatedly, it no longer seems possible to mark typealiased closures as
@escaping. That was quite handy when you know that closures will always be used
asynchronously.
Jon
> On Sep 7, 2016, at 6:15 PM, Shawn Erickson via swift-users
> wrote:
>
> I should note
I should note that this issue also appeared in an earlier variant of Swift
after the addition of @escaping but I was on vacation so didn't get a
chance to report it then. It isn't new with the Xcode 8 GM.
On Wed, Sep 7, 2016 at 3:08 PM Shawn Erickson wrote:
> I like and fully
I like and fully supported the change to @escaping away from @noescape
however in a body of code that I am porting to the latest Swift 3 variant
(as found in Xcode 8 GM) I am hitting an issue for methods that take an
optional completion closure. If optional is involved I can't find a way to
apply
It’s related to this:
http://www.cocoawithlove.com/blog/2016/07/12/type-checker-issues.html
Jon
> On Sep 7, 2016, at 11:32 AM, Lou Zell via swift-users
> wrote:
>
> Also hoping someone more knowledgeable can explain why these seemingly simple
> cases do in fact take
oups! typo!
the real test:
let
simpleTest = Float(abs(11 - -3) + abs(4.5 - -4)) //!
print ("simpleTest: \(simpleTest)")
Le 07/09/2016 à 10:33, Alex Blewitt a
écrit :
On 7 Sep 2016, at 15:11, louislepegue via
Hi
This simple instruction can take more than 20 seconds to execute
and near 100% CPU on different Linux Swift version I tested.
Also tested in compiled mode with the same result.
let simpleTest = Float(abs(11 - -3) + abs(4.5 -
-4)) //!
print
Now I understand your point. But as Jens said, Swift is a static language,
it won't interpret `property` as a variable after `.`(dot). So for Swift
compiler, you just refer to a none-exist property.
Zhaoxin
On Wed, Sep 7, 2016 at 12:39 PM, Michael Sheaver wrote:
> Hi Zhao,
>
>
19 matches
Mail list logo