>
> 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 an
> On Sep 3, 2016, at 6:03 PM, Gerard Iglesias via swift-users
> wrote:
>
> This is my funny version… I succeeded and I didn’t come back to find an other
> way…
>
> // Grab a pointer to the constant buffer's data store
> // Since we are using Swift, it is easier to cast the pointer to the
> S
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 supplies it with an e
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 Shawn
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 supplies it with an error is one exists (e.g. an error
happened).
It doesn't make sense for this function (the one you implement) to
I seem to have hit a possibly related @escaping issue...
The following code worked without issue under Swift 2.x and earlier
variants of Swift 3 but after the @escaping change (fairly sure that is
what is at fault) it no longer compiles.
protocol Foo {
// Happy
func visitValues(visitors:
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, 20
To more completely state what I find it a little strange.
The default was moved to be non-escaping since that is the better default
(for various reason) with @escaping being used to both inform the compiler
that something is intentionally escaping (yeah I meant to do that) and to
me it seem also h
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 I
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, activationDidComplete
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
confusi
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 functi
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, @escaping
--
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 myself that I can no l
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 used asynchronously.
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 that this issue also ap
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 supported the chang
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 @
Thanks
A must reading, at least I understand that is a compiler bug that
could happen with type conversion. Also, a workaround can be
easily done.
On this September 7, I hope that we will have a new release :-)
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 so long! :)
> __
Also hoping someone more knowledgeable can explain why these seemingly
simple cases do in fact take so long! :)
Matt Gallagher wrote an excellent article where he explained how
seemingly simple expressions can sometimes cause an enormous amount of
work for the type checker because it has so ma
Also hoping someone more knowledgeable can explain why these seemingly
simple cases do in fact take so long! :)
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
>
> It's certainly an interesting compiler issue, probably to do with the type
> analysis
I've for sure hit this before and now see with a little help to the
compiler the compile time drops dramatically:
Float(abs(Double(0) - Double(0)))
repl.swift:50:1: error: expression was too complex to be
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 s
On 7 Sep 2016, at 15:11, louislepegue via swift-users
wrote:
>
> let simpleTest = Float(abs(11 - -3) + abs(4.5 - -4)) //!
> print ("simpleTest: \(Simpletest)")
>
Aside from the fact that the case-sensitivity of simpleTest is important, the
delay is in the compilation of this script rather t
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
Can't mirrors solve this problem for Locale itself, instead of using NSLocale?
I do think that will affect performance though.
Rugen
> On 7 Sep 2016, at 09:03, Zhao Xin via swift-users
> wrote:
>
> Now I understand your point. But as Jens said, Swift is a static language, it
> won't interpre
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,
>
> Many thanks for y
29 matches
Mail list logo
