|
Is it possible to have a protocol's default implementation in an extension work for selectors? For example, I'd like an extension to provide some gesture recognizers:code:
|
# ? Sep 25, 2015 04:44 |
|
|
# ? May 14, 2024 23:42 |
|
Maybe the protocol (and the methods in it too, perhaps) need to be marked @objc?
|
# ? Sep 25, 2015 06:47 |
|
It's an area of some debate, but at least some variants of it would probably be okay, and the current inability to do that is just an unnecessary restriction.
|
# ? Sep 25, 2015 08:16 |
|
Flobbster posted:Maybe the protocol (and the methods in it too, perhaps) need to be marked @objc? I tried that but the compiler yells at you "Members of protocol extensions cannot be declared as @objc". rjmccall posted:It's an area of some debate, but at least some variants of it would probably be okay, and the current inability to do that is just an unnecessary restriction. Oh okay, cool. Well here's a +1 to allowing that in a future release of Swift. I should be fine maybe making a lightweight base class that'll receive the selectors for the time being (or something to that effect). Also really enjoying 2.0 so far, great job
|
# ? Sep 25, 2015 12:50 |
|
The real solution is to replace methods that take selectors with methods that take functions. I was rather disappointed that iOS 9 didn't do that through more of UIKit.
|
# ? Sep 25, 2015 18:14 |
|
Axiem posted:The real solution is to replace methods that take selectors with methods that take functions. I was rather disappointed that iOS 9 didn't do that through more of UIKit. Definitely. I just hobbled together an extension on UIGestureRecognizer to do just this with some object association. Feels pretty dirty.
|
# ? Sep 26, 2015 22:48 |
|
Is it possible to write a generic function that returns a random normalized value and infers the type? This sounds like a good use for generics so I don't have to have Float, Double, CGFloat versions of the same function. Something like: func randomNormalized<T: FloatingPointType>() -> T My attempts have all failed because I can't seem to initialize the resulting T.
|
# ? Sep 27, 2015 23:59 |
|
Sure. If you check the FloatingPointType protocol you will see it includes initialisers from all of the integer types, so you can docode:
code:
|
# ? Sep 28, 2015 07:12 |
|
jawbroken posted:Sure. If you check the FloatingPointType protocol you will see it includes initialisers from all of the integer types, so you can do
|
# ? Sep 28, 2015 16:21 |
|
Is there any plan for any sort of preprocessing steps in the future? I'm thinking up to even Scala's macros, where we could run arbitrary Swift on the code as a build step. It seems like it'd be nice to have to something like C#'s async/await transforms.
|
# ? Oct 1, 2015 21:44 |
|
Doh004 posted:Definitely. If anyone's curious, I put up a repo with my Draggable extension: https://github.com/BayPhillips/draggable-swift
|
# ? Oct 3, 2015 21:21 |
|
I have a few questions. What is going on here? Why doesn't tuple unpacking work the way I expect?code:
code:
code:
code:
Why is it not able to find a match between the parameter list and the protocol constraint and use that?
|
# ? Oct 22, 2015 14:42 |
|
emoji posted:I have a few questions. What is going on here? Why doesn't tuple unpacking work the way I expect? The first function takes a tuple of type (Int,Int) because you've suppressed the label, so the y-labeled arguments don't match anything. The second takes a tuple of type (Int, y: Int), so the y-labeled argument matches now, but the x-labeled argument doesn't. In all cases, the diagnostics could be better. emoji posted:Also, will it be possible to have generic computed properties like so, or is it and I'm doing it wrong? I don't think we actually want to add generic properties, no. Maybe someday. emoji posted:It also tells me for f3: note: overloads for 'float3' exist with these partially matching parameter lists: (Float), ([Float]), (SCNVector3) Not sure.
|
# ? Oct 22, 2015 17:22 |
|
This is probably more for rjmccall directly, but is there a way to get lldb to know about C types you'd usually use in the ObjC world? Mostly I'm trying to fix Chisel to deal with being on a Swift frame in the debugger while trying to execute an ObjC expression. What I'm seeing is if you run "expr -l ObjC++ -- (NSInteger)1", it works when you're in an ObjC or ObjC+Swift Xcode target, but in a strictly-Swift one it fails out saying "use of undeclared identifier 'NSInteger'". Is there a way to get lldb to pull in the ObjC stuff at runtime?
|
# ? Oct 23, 2015 07:32 |
|
I have no idea, sorry. We are doing infrastructural things that should lead to a much more complete debugging experience, and it should lead to types like NSInteger being reliably available; but I don't know what the schedule for that is expected to be.
|
# ? Oct 23, 2015 09:13 |
|
Is there a way yet to constrain a generic type parameter to be a subclass of or conform to another generic type parameter? Let's say I want to pass in two type objects to a function, the second of which extends the first. If this were Java, I would just say something like: code:
code:
So is there any way to say "T must be a class" or "T must be a protocol"?
|
# ? Oct 24, 2015 18:40 |
|
I don't have a compiler at hand, but I believe T : class will constrain it to be a class type. However, I'd be surprised if you could then use T as the "concrete" bound on a different parameter.
|
# ? Oct 25, 2015 07:01 |
|
Alternatively, though, do you really need to type the second as U.Type? Class metatypes have subtyping that follows inheritance.
|
# ? Oct 25, 2015 07:03 |
|
rjmccall posted:I don't have a compiler at hand, but I believe T : class will constrain it to be a class type. However, I'd be surprised if you could then use T as the "concrete" bound on a different parameter. I already tried that hoping it would work since that's how you create a class-only protocol, but no such luck—the parser isn't remotely cool with it (Xcode 7.1/Swift 2.1): code:
quote:Alternatively, though, do you really need to type the second as U.Type? Class metatypes have subtyping that follows inheritance. Assuming everything else worked like I'm intending, I'd have to type both as T.Type/U.Type or both as T/U, right? In my example above, if I wrote: code:
|
# ? Oct 25, 2015 17:59 |
|
I just mean that Subclass.self : Superclass.Type. It's silly that you can't write T : class as a constraint, but T : AnyObject will probably have the desired effect, although again it probably won't let you express what you want.
|
# ? Oct 26, 2015 07:38 |
|
Thanks. Writing T: AnyObject does the right restriction there but trying to do U: T gives me the same "inheritance from non-protocol, non-class type 'T'" error. It occurs to me that I would want something more general for what I'm trying to do; instead of just classes, the ideal constraint would let me express "let T be any type for which there is some other type U that can conform to or inherit from T" (so T could be a protocol or a class), and then I could write "U: T" as a subsequent type argument and the compiler would be ok with that. Between this and some tricky tuple-unpacking, I think I'm just trying to do some C++-style metaprogramming that Swift isn't able to handle (...yet?)
|
# ? Oct 28, 2015 03:25 |
|
Yeah, it sounds like you're looking for some sort of polymorphism over constraints that is probably waaay into undecidability territory. But I suspect that the correct answer to "what are you actually trying to do" is much simpler than that.
|
# ? Oct 28, 2015 07:45 |
|
What does it mean for a class to support NSFastEnumeration?code:
|
# ? Oct 30, 2015 01:01 |
|
Implementing NSFastEnumeration only lets you iterate it from objc. To make it enumerable in swift you have to implement SequenceType.
|
# ? Oct 30, 2015 01:11 |
|
Plorkyeran posted:Implementing NSFastEnumeration only lets you iterate it from objc. To make it enumerable in swift you have to implement SequenceType. Check, thanks.
|
# ? Oct 30, 2015 01:19 |
|
lord funk posted:What does it mean for a class to support NSFastEnumeration? It means it conforms to the Objective-C NSFastEnumeration protocol, which is not at all new in Swift. lord funk posted:I'm getting this when I try to do it: The Swift for..in syntax requires a conformance to the Swift SequenceType protocol, not NSFastEnumeration. There's a NSFastGenerator that makes it super-easy to conform to SequenceType if you have a value that conforms to NSFastEnumeration, but it sounds like you really want to go the other way: you just want your class to conform to SequenceType.
|
# ? Oct 30, 2015 01:21 |
|
So this is a thing: http://perfect.org/ "web brains"
|
# ? Nov 24, 2015 02:33 |
|
Everyone's beating me to the Swift-on-the-backend bandwagon cuz I have a day job and a new baby and poo poo. (https://github.com/allevato/SwiftCGI, still just tinkering, ignore the jacked up Xcode project structure I have to deal with unit tests right now) Browsing through the Perfect source code, it's pretty disappointing though. Looks like everything's a drat class—they're just writing code but not taking full advantage of the unique design features of the language. But at least they've got a pretty web page for it!
|
# ? Nov 24, 2015 03:11 |
|
Flobbster posted:Everyone's beating me to the Swift-on-the-backend bandwagon cuz I have a day job and a new baby and poo poo. (https://github.com/allevato/SwiftCGI, still just tinkering, ignore the jacked up Xcode project structure I have to deal with unit tests right now) So it's not perfect?
|
# ? Nov 24, 2015 03:20 |
|
I'm migrating classes in a large Objective-C project to Swift. I've found that if you expose a Swift class using a custom name via @objc, the Swift class can no longer see methods in Objective-C classes that reference that name. Example: code:
code:
code:
|
# ? Nov 25, 2015 20:36 |
|
Oh, interesting. I suspect there's just a missing feature there: the type is purely forward-declared in ObjC, and we normally can't import those into Swift because we don't want to introduce the concept of an incomplete type into the language, but here we ought to be able to match it up with a Swift declaration. The workaround, unfortunately, is probably just to make the ObjC declaration less type-safe. Our usual recommendation right now is to convert from the leaves in. Of course, that's not really optimal for anyone because it's the core classes that are more interesting to Swift-ify.
|
# ? Nov 25, 2015 20:47 |
|
I filed rdar://23666040 with a sample project containing the code posted here.
|
# ? Nov 25, 2015 21:08 |
|
Thanks!
|
# ? Nov 25, 2015 23:21 |
|
Not sure if this was covered, but when Swift is open-sourced, a) will its Objective-C bridging be intact? and b) does this mean there's a possibility that in addition to the Swift runtime, release of a more liberally-licensed Objective-C runtime (i.e. NCSA, instead of APSL) is possible in addition? (because seriously, GNUstep, Cocotron, and WinObjC? )
|
# ? Nov 30, 2015 23:34 |
|
I really can't answer any of that, sorry.
|
# ? Dec 1, 2015 04:37 |
|
"Apple engineer doesn't deny plans to release new runtime!"
|
# ? Dec 1, 2015 05:28 |
|
Speaking of, when is Swift going to be open-sourced, again? I could have sworn it was sometime soon.
|
# ? Dec 1, 2015 15:45 |
|
Axiem posted:Speaking of, when is Swift going to be open-sourced, again? I could have sworn it was sometime soon. According to the swift subreddit still on track to EOY 2015
|
# ? Dec 1, 2015 17:36 |
|
Official announcement is up, although the linked repos are still private. In addition to the obvious things it includes Foundation, XCTest, and a package manager.
|
# ? Dec 3, 2015 16:39 |
|
|
# ? May 14, 2024 23:42 |
|
#calledit (sorta?)
|
# ? Dec 3, 2015 17:16 |