|
It's apparently a reimplementation of Foundation's API without any obj-c involved, which seems like an odd choice to me.
|
# ? Dec 3, 2015 17:21 |
|
|
# ? May 30, 2024 13:18 |
|
Developed under Apple's banner, with their name taking the reputation hit it if sucks rear end (it won't) is good enough for me, I think, because a) it aligns their incentives with making it not crap, b) it'll be consistent across platforms to the degree it can be, and c) they have the technical resources on hand to refer to with regards to issues with the original Foundation implementation. And it means also that maybe they'll adopt Swift's Foundation over time – maybe. Also, a commitment to make libdispatch a better option on non-Darwin platforms is very, very welcome news. Now Linux people can (officially) see the light of GCD*! * yeah, yeah, it wasn't impossible before, with libpthread-workqueue, but again, official support is awesome
|
# ? Dec 3, 2015 17:27 |
|
Congrats, rjmccall!
|
# ? Dec 3, 2015 17:28 |
|
Plorkyeran posted:It's apparently a reimplementation of Foundation's API without any obj-c involved, which seems like an odd choice to me. That explains why it took so long. That's quite the undertaking. Nice to see that (based on comments, since Swift.org has been crushed by the traffic) Apple open sourced all of the basics necessary to make Swift useful for backend programming. I was concerned they were going to open source the language and nothing more. Granted that would have been at odds with their stated goals of making Swift a systems language, but you never know. Hopefully this means useable web/backend frameworks will start popping up. Exciting stuff!
|
# ? Dec 3, 2015 17:29 |
|
Now I'll have to satisfy my neckbeard impulse to demand virtually impossible things by complaining that Core Data isn't open-source! No but seriously, I am seriously stoked to see/use/program Swift on the backend.
|
# ? Dec 3, 2015 17:32 |
|
Man, they told us 10am, I thought I had plenty of time to come in and vaguepost. Yeah, we definitely recognized the need to deliver a richer library experience on other platforms. C interop is one thing, but the POSIX APIs are pretty creaky, and there's not really much of an accepted higher layer on top of most of them at the C level. My hope, and to a degree my expectation, is that the Foundation APIs will evolve in a Swiftier direction as the community begins to drive that development; but they're a fine basis from which to start the discussion.
|
# ? Dec 3, 2015 17:57 |
|
Sooo cool! It's not that I didn't believe it would happen, but you just never know until it does. Congrats!
|
# ? Dec 3, 2015 17:59 |
|
Accepted proposal: Remove the ++ and -- operators
|
# ? Dec 3, 2015 18:17 |
|
I'm torn between and
|
# ? Dec 3, 2015 18:54 |
|
I love it. Too few languages get that sort of thoughtful design attention to existing features after they're in production use. I'm occasionally annoyed by Swift compatibility woes (mostly when bisecting), but I'm mostly jealous that they can keep refining the language so substantially.
|
# ? Dec 3, 2015 18:59 |
|
Removing function currying's the bigger one (and also one that I agree with, as I've never actually seen it used).
|
# ? Dec 3, 2015 19:18 |
|
++/-- was a fun conversation internally. I got to lead a faction that stubbornly withheld support until Chris gave in and admitted that Swift 3 was a major source break and that we would need to plan around that. Anyway, go read the Better Translation of Objective-C APIs Into Swift proposal.
|
# ? Dec 3, 2015 19:19 |
|
Subjunctive posted:Congrats, rjmccall!
|
# ? Dec 3, 2015 19:25 |
|
Yeah this is more super cool stuff
|
# ? Dec 3, 2015 19:38 |
|
rjmccall posted:My hope, and to a degree my expectation, is that the Foundation APIs will evolve in a Swiftier direction as the community begins to drive that development; but they're a fine basis from which to start the discussion. So loving pumped for this, rjmccall.
|
# ? Dec 3, 2015 19:41 |
|
So with Swift open source I'm curious how new libraries are going to be developed using it. Isn't there a concern that the ecosystem is going to be a bit confusing when some Swift "general purpose" libraries won't work on anything but iOS, or whatever, just due to the nature of the dependencies being relied upon? Will we see a pattern where these libraries move away from iOS/OSX specific dependencies to platform agnostic dependencies so that they can work on Linux. Take Alamofire for example, which uses NSURLSession. I guess it would be no more confusing than C/C++, and perhaps this is something the Swift Package Manager is also trying to address. EDIT: I just saw the the foundation stuff. Okay thats pretty neat then. xgalaxy fucked around with this message at 20:08 on Dec 3, 2015 |
# ? Dec 3, 2015 19:58 |
|
Congrats to rjmccall and the whole team on what must have been a massive amount of work. You even imported the entire SVN commit history which is extremely brave. I'm pleasantly surprised to be wrong(-ish) about the Foundation thing! Some of the proposals in the swift repo are quite interesting, including concurrency. It is also interesting to see how some features evolved or what was rejected. I'm probably going to be useless for the rest of the week as I spend my time browsing the sources and reading up. Does anyone know if us plebs can get Xcode to use a custom build of swift or sourcekitd? I haven't looked into it yet.
|
# ? Dec 3, 2015 20:13 |
|
Ender.uNF posted:Congrats to rjmccall and the whole team on what must have been a massive amount of work. You even imported the entire SVN commit history which is extremely brave. We did have to munge a few things — internal codenames, privileged presentations, that sort of thing — but yeah, the whole semantic history of the actual code base is intact.
|
# ? Dec 3, 2015 20:32 |
|
Ender.uNF posted:Does anyone know if us plebs can get Xcode to use a custom build of swift or sourcekitd? I haven't looked into it yet.
|
# ? Dec 3, 2015 20:40 |
|
Doctor w-rw-rw- posted:Now I'll have to satisfy my neckbeard impulse to demand virtually impossible things by complaining that Core Data isn't open-source! There's already a GPLv3 relicensing PR, in addition to the expected typo PRs.
|
# ? Dec 3, 2015 21:03 |
|
Toady posted:There's already a GPLv3 relicensing PR, in addition to the expected typo PRs. And a million comments on the first commit. It's highly annoying.
|
# ? Dec 3, 2015 21:57 |
|
Ender.uNF posted:And a million comments on the first commit. It's highly annoying. Gotta make that impact. Get your name out there!
|
# ? Dec 3, 2015 22:07 |
|
ultramiraculous posted:Gotta make that impact. Get your name out there! The endless PRs that fix a single typo in a comment are a slightly less obnoxious form of that.
|
# ? Dec 3, 2015 23:52 |
|
Plorkyeran posted:The endless PRs that fix a single typo in a comment are a slightly less obnoxious form of that. • Contributor to open-source Swift project since December 2015
|
# ? Dec 4, 2015 00:14 |
|
Toady posted:There's already a GPLv3 relicensing PR, in addition to the expected typo PRs. The GPL license PR is from "mooman219", the trolls are coming from inside the forums
|
# ? Dec 4, 2015 00:33 |
|
Evolution proposal: call the package manager for Swift "tailor".
|
# ? Dec 5, 2015 01:51 |
|
swift ev proposal, murder everyone who makes grammar PRs
|
# ? Dec 5, 2015 02:50 |
|
I just saw a typography PR go by. They reformatted a document to use French spacing. One of my documents. Animals.
|
# ? Dec 5, 2015 03:22 |
|
rjmccall posted:I just saw a typography PR go by. They reformatted a document to use French spacing. One of my documents. Animals. Burn them!
|
# ? Dec 5, 2015 03:39 |
|
Snapchat A Titty posted:Burn them! Figure a guillotine would be more appropriate!
|
# ? Dec 5, 2015 06:09 |
|
I need to create an UnsafeMutablePointer of either type UInt16 or UInt32 to match an MTKSubmesh's MTKIndexType. I'm having trouble with the syntax. This doesn't work, but should show what I want: code:
|
# ? Dec 11, 2015 21:38 |
|
lord funk posted:I need to create an UnsafeMutablePointer of either type UInt16 or UInt32 to match an MTKSubmesh's MTKIndexType. I'm having trouble with the syntax. I'm pretty sure this isn't possible for a couple reasons: 1) There's no common type that the compiler can use for the variable in line 1 that would match both UInt16.Type and UInt32.Type 2) Because of that, you can't have a runtime decision decide the compile-time type of pointerToIndexData in line 2. You're asking pointerToIndexData to be UMP<UInt16> sometimes and UMP<UInt32> other times based on stuff happening while the program is running. Can you do something like this instead? code:
|
# ? Dec 12, 2015 01:30 |
|
Flobbster posted:Can you do something like this instead?
|
# ? Dec 12, 2015 16:16 |
|
So is there a libclang-equivalent for Swift/does libclang support Swift and I'm just not using the right incantations? It seems like Realm devs are the only people really exploring this and they're exclusively using SourceKit calls they've sniffed out.
|
# ? Jan 5, 2016 06:26 |
|
SourceKit is supposed to be the libclang equivalent; it's just not open-source yet.
|
# ? Jan 5, 2016 06:31 |
|
Er, is there something beyond https://github.com/apple/swift/tree/master/tools/SourceKit to open-source? There isn't really user documentation but it appeared to have all of the actual functionality.
|
# ? Jan 5, 2016 06:43 |
|
That's what I figured. Any tips on AST traversal?
|
# ? Jan 5, 2016 06:44 |
|
Plorkyeran posted:Er, is there something beyond https://github.com/apple/swift/tree/master/tools/SourceKit to open-source? There isn't really user documentation but it appeared to have all of the actual functionality. Oops. I know there are some things around IDE integration we haven't open-sourced, and I'm phone-posting and couldn't remember if SourceKit was one of them. Good.
|
# ? Jan 5, 2016 06:50 |
|
ultramiraculous posted:That's what I figured. Any tips on AST traversal? I don't know the SourceKit interface at all, sorry.
|
# ? Jan 5, 2016 06:51 |
|
|
# ? May 30, 2024 13:18 |
|
I think the C API currently just exposes the IDE support functionality, which is basically just "tokenize this string" and "tell me about whatever's at this offset". For an AST you'd have to access the guts of the implementation (for Swift Jazzy just tokenizes the file then does the equivalent of alt-clicking each token and then reconstructing the structure).
|
# ? Jan 5, 2016 07:01 |