Just one more thing - Swift thread - The Something Awful Forums

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Just one more thing - Swift thread

«‹›4 »

Simulated: Sep 28, 2001; Lowtax giveth, and Lowtax taketh away.; College Slice

Beta 4 is out!

I'm curious what the reason for requiring the indirect keyword is... why not just detect recursive enums and handle it automatically? I assume there is a performance or space cost for it?

On the Objective-C nullability qualifiers (and this applies to __block, et al as well): Why can't the compiler contextually handle these as keywords and drop the leading underscores? In the extremely rare case you have functions or variables named "nullable" surely the compiler can determine "NSString * nullable x;" is a declaration? It still bothers me every time I see it. Is it the preprocessor? Some ambiguous case in the grammar?

P.S. Thank you for 21718497. It was killing me.

# ¿ Jul 21, 2015 23:04

Adbot: ADBOT LOVES YOU

# ¿ May 14, 2024 03:47

Simulated: Sep 28, 2001; Lowtax giveth, and Lowtax taketh away.; College Slice

lord funk posted:

Is there something other than using po in the debugger that I should be aware of? po is constantly finding new ways to not show me anything at all, even as the local variable list shows me the objects I want to inspect.

LLDB gets very confused with certain Swift constructs. I haven't been able to find a pattern yet. Seemingly simple classes will cause the debugger to say it can't po self or some local variable. Closures seem to make it worse. In every case the variables pane shows everything just fine.

Like the random nonsense errors you get when the contents of a closure are invalid you just work around it.

# ¿ Aug 16, 2015 18:25

Simulated: Sep 28, 2001; Lowtax giveth, and Lowtax taketh away.; College Slice

Starting to really feel the pain of Xcode 7 forcing a Swift 2 upgrade. It makes maintaining branches difficult.

I totally understand wanting to push the language forward and I agree with it, but perhaps the compiler & standard library could support the old stuff (but deprecated) for a single release. If we could just get away with both for six months it would be relatively painless.

# ¿ Aug 18, 2015 20:42

Simulated: Sep 28, 2001; Lowtax giveth, and Lowtax taketh away.; College Slice

Plorkyeran posted:

Installing Xcode 6 and 7 side-by-side works fine. I've been switching between them many times per day ever since the first beta came out, and literally the only problem I've encountered is that you have to explicitly exit the simulator when switching or dumb things happen.

That stops being so much fun when you have to keep an iOS 9 branch going while working on other feature branches. You basically can't interact with the iOS 9 branch.

# ¿ Aug 19, 2015 01:33

Simulated: Sep 28, 2001; Lowtax giveth, and Lowtax taketh away.; College Slice

Plorkyeran posted:

Maintaining Swift 1.2 and Swift 2.0 versions of code has certainly been an utter nightmare, but having to keep track of which copy of Xcode I'm looking at is one of the smallest of the annoyances. I guess not being able to use the iOS 9 SDK with Swift 1.2 is an unnecessary headache.

I don't think we are talking about the same things.

Xcode 7 is the only version that can use the iOS 9 SDK.
Xcode 7 will only build Swift code that uses Swift 2 syntax.
The changes make it extremely difficult to merge changes from other branches into our iOS 9 branch or vice-versa.
This directly leads to either making iOS 9 changes blind, fighting merge hell, or constantly re-running the conversion.

Separate question: can anyone make the case for not having an optional assignment operator?

code:

infix operator ?= { associativity right precedence 90 }
func ?= <T>(inout lhs: T, rhs: T?) {
    if let rhs = rhs {
        lhs = rhs
    }
}

# ¿ Aug 20, 2015 00:05

Simulated: Sep 28, 2001; Lowtax giveth, and Lowtax taketh away.; College Slice

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

Simulated: Sep 28, 2001; Lowtax giveth, and Lowtax taketh away.; College Slice

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

Simulated: Sep 28, 2001; Lowtax giveth, and Lowtax taketh away.; College Slice

rjmccall posted:

Well, don't get your hopes up.

Can you go over to dev tools and smack whoever broke the SourceKit notification banner? I've been getting massive numbers of crashes (especially when it involves generics and type inference) which wouldn't be so bad... except now Xcode has a ~40% chance of crashing when SourceKit crashes. I'm back to restarting Xcode multiple times per hour.

Not directed at you: There also appears to be a huge impedance mismatch between SourceKit as Xcode uses it and the real compiler because I get no autocomplete in my framework unit test target (all types from the framework itself import as <<error type>> but everything compiles and runs just fine). Unfortunately trying to replicate this in a sample project failed - everything works - so there is something about larger projects or more complex dependencies that I haven't been able to diagnose. Funny enough the main app and it's unit test target don't have this problem. I haven't filed a radar because I don't have anything useful to provide besides "hurrrr broken".

# ¿ Jan 30, 2016 05:48

Simulated: Sep 28, 2001; Lowtax giveth, and Lowtax taketh away.; College Slice

I'll be honest... I don't see the point either. I guess it removes some verbosity but I'd rather people spent time on concurrency or improved reflection support but whatever.

# ¿ Jan 30, 2016 20:41

Simulated: Sep 28, 2001; Lowtax giveth, and Lowtax taketh away.; College Slice

Flobbster posted:

Is this intentional? I wonder if there are any obscure and unwise tricks you can do with this.

The answer is always yes. No one expects ~~the spanish inquisition~~ globals to be side-effecting getters/setters.

# ¿ Jan 31, 2016 01:36

Simulated: Sep 28, 2001; Lowtax giveth, and Lowtax taketh away.; College Slice

Subjunctive posted:

Every single person involved in Swift knew that opening language direction to public discussion was going to be like chewing glass. For none of them is this the first rodeo, and all these rodeos suck. They're a huge distraction and emotionally draining.

And yet, because it leads to a marginally better language and much stronger ecosystem, they braced themselves and took a nice big bite. Even if I thought they were wrong about everything, I'd still have a ton of respect for their willingness to engage and their admirable demeanor while doing so. They are doing all the right things to build a language and community that deserves to underpin the most important software ecosystem since the web, and they don't have to. They had to fight and sacrifice and make enemies at Apple in order to be allowed to open the door and get a tomato in the face.

Whether I agree with their decisions or not (lol, "trimming"), it's exactly the sort of team I'd want designing a language I bet my livelihood on. If they find themselves in MPK, the drinks are on me.

Agreed; Even though I don't think the renaming proposal is all that important I trust the Swift team and I know they've had lots of internal arguments about it so I'm just going to wait and see how it works in practice.

I'm also mostly staying away from swift-evolution (besides the fact that I have a real job and my own side project app [that will surely be rejected in review]).

# ¿ Feb 5, 2016 00:07

Simulated: Sep 28, 2001; Lowtax giveth, and Lowtax taketh away.; College Slice

Flobbster posted:

Does this mean you're also looking at ways make it easier to write fluent interfaces/builders with structs? Right now having the initializer result be immutable is a showstopper because I can't write "let foo = Foo().something(5).somethingElse(10)" even if those methods are mutating.

I've been working on a side project where I've had an opportunity to really use protocol-oriented programming, extensions, constraints, and generics in some cool ways and I've gotta say, I love just how algebraically Swift lets me design components. Being able to say "this type implements this set of methods, but also this superset of additional methods if the associated type is X" is mind blowing. And I've only written one class, and it was purely an implementation detail to get copy-on-write for a value type.

We've found this to be the case as well. My rough guess right now is we're going to end up deleting about 20,000 - 30,000 lines of code when the core sync/database logic is fully converted to Swift, if not more.

# ¿ Feb 26, 2016 09:15

Simulated: Sep 28, 2001; Lowtax giveth, and Lowtax taketh away.; College Slice

I just wanted to say kudos to the whole Swift team regarding swift-evolution and the development process. It's awesome watching the discussions and the progress of the entire project.

# ¿ Mar 4, 2016 19:04

Simulated: Sep 28, 2001; Lowtax giveth, and Lowtax taketh away.; College Slice

Subjunctive posted:

Well, the incompatible-version churn of Swift has to stop at some point soonish, I think (I haven't kept up with published plans if any). Swift code in The Ecosystem will shed its Obj-C interoperability overhead as the set of people who need that interop declines. We're still a fair ways from adopting Swift at all, let alone replacing all of our Obj-C with it, but just as you can have extern "C" boundaries around a C++ library, I can imagine chokepoints that let the core of the app develop without worrying about Obj-C interop.

I did my best with SE-0058 but it got deferred. It would have made bridging to Objective-C a lot nicer. My current plan is to poke apinotes and see if there is any hope in that direction.

# ¿ May 11, 2016 23:58

Simulated: Sep 28, 2001; Lowtax giveth, and Lowtax taketh away.; College Slice

rjmccall posted:

All of these questions are somewhat tied together. The interesting thing about that protocol is that it's (almost) exactly the right protocol for changing the bridging of an arbitrary C type, not just ObjC classes, and that's a pretty useful thing to consider having. It's just that there are other important questions about bridging that we have to resolve first � for example, do we need to design bridging protocols to fit into the dynamic-cast system, or are we going to just remove all of that and make dynamic cast only respect natural subtyping? And should we separate both directions of mapping?

Oh yes, it totally makes sense for Swift as an open source project. It just sucks for me personally because now I have to write a lot more glue code. Not the end of the world by any stretch.

# ¿ May 17, 2016 02:36

Simulated: Sep 28, 2001; Lowtax giveth, and Lowtax taketh away.; College Slice

sarehu posted:

Okay on that note I'll retract calling sizeof(T) "wrong." On the other hand if you're optimizing struct packing like this, sizeof(Int) could stand to be 4 bytes to save some cache line space...

You're typically operating on an UnsafePointer which knows the size/stride anyway. Swift doesn't currently have an easy way to deal with packed values at all.

# ¿ May 24, 2016 05:08

Simulated: Sep 28, 2001; Lowtax giveth, and Lowtax taketh away.; College Slice

Doctor w-rw-rw- posted:

Some commentary on dynamism in Swift: http://mjtsai.com/blog/2016/05/21/dynamic-swift-2/

quote:

No one doubts that this team will produce a great language for writing a compiler�the question is how it will handle apps. Apple is attempting something very ambitious: a single language that can span the spectrum. They are in uncharted territory, which is why people don�t know exactly what to expect.

Members of the Swift core team have explicitly said they have no plans to rewrite Swift in Swift right now precisely because that leads to language suited to building compilers. None of them have expressed a disregard or distain for the problems of app developers. I just think Swift is being ambitious in trying to be a systems programming language and app development language.

Almost every example of something that requires dynamism is not a real example, it's just Apple developers thinking only in terms of how the existing SDKs and Interface Builder work. The complaints about code generation are because they've never used good code generation. Visual Studio represents all visually designable elements as code and it works really well. It injects stored properties and statically typed event handlers through extensions. Interface Builder could do the same thing and instead of having to drag between IB and code it could just happen automatically.

Swift needs a good safe macro/metaprogramming system. It needs good reflection. It does not need objc_msgSend or swizzling.

# ¿ May 27, 2016 22:50

Simulated: Sep 28, 2001; Lowtax giveth, and Lowtax taketh away.; College Slice

emoji posted:

You can define custom subscript accessors for your data structure.

https://developer.apple.com/library...4097-CH16-ID305

I would add that subscripts can have multiple indices so this works just fine:

code:

subscript(first: Character, second: Character) -> Character { }
...
let result = s[A, B]

Then the internal storage characteristics are irrelevant to users of the type.

You're constructing a matrix so using a two-dimensional array or offsets into a one-dimensional array would work just fine.

# ¿ Jun 9, 2016 00:09

Simulated: Sep 28, 2001; Lowtax giveth, and Lowtax taketh away.; College Slice

Yup, all the Swift 3 stuff has been part of the normal process.

# ¿ Jun 14, 2016 04:01

Simulated: Sep 28, 2001; Lowtax giveth, and Lowtax taketh away.; College Slice

So Matt Gallagher makes an interesting argument that Swift's type constraint system solver can be made linear time instead of exponential, eliminating the stupid "expression too complex to type check" error.

http://www.cocoawithlove.com/blog/2016/07/12/type-checker-issues.html

He freely admits that he isn't qualified to say whether his proposed solution is good enough or has fatal flaws. Frankly I'm not qualified to make that judgement either. I was hoping rjmccall or someone else with compiler type system experience could shed some light?

# ¿ Jul 19, 2016 03:38

Simulated: Sep 28, 2001; Lowtax giveth, and Lowtax taketh away.; College Slice

C# already did this the correct way. By default if the name matches it is selected as the protocol (interface) implementation. If you want to be fancy then you explicitly specify which interface you are implementing. The vast majority of programmers never have to think about it, but you have options if you run into a complex scenario.

# ¿ Sep 22, 2016 05:38

Simulated: Sep 28, 2001; Lowtax giveth, and Lowtax taketh away.; College Slice

dc3k posted:

Coworker brought up this posting today: https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20160307/001384.html

We just recently (today) enabled WMO on our debug builds, and noticed a drastic decrease in build times. Up until now, our build times have been loving insane. On a Mac Pro, clean builds used to take 20 to 25 minutes, and incremental builds anywhere from a few seconds to 15 minutes. Incremental builds were notably slow when modifying enums and extensions. Now that WMO is on across all of our modules, we're seeing clean builds of about 6 minutes, and incremental builds of ~4 minutes and under. I know this is an older posting, but I'm wondering if anyone can shed some light on this?

This is just a guess but when you aren't doing WMO each file gets a separate invocation of the compiler like traditional C code so there may be a lot of duplicate work going on. WMO is probably taking advantage of keeping the ASTs, type resolution caches, etc in the same process. rjmccall would know more.

# ¿ Oct 18, 2016 05:44

Simulated: Sep 28, 2001; Lowtax giveth, and Lowtax taketh away.; College Slice

Fortunately we have an easy out without breaking source compatibility; revert private to its old behavior and make fileprivate a synonym.

Not all changes will be winners; that's true whether the change comes from behind closed doors or from an open community-driven process. The important thing is that we recognize when this is the case and fix it.

Personally I'd like to see more use of experimental things behind feature flags so we can get real-world experience before we commit but there are obvious downsides to that.

Simulated fucked around with this message at 23:42 on Feb 19, 2017

# ¿ Feb 19, 2017 23:38

Adbot: ADBOT LOVES YOU

# ¿ May 14, 2024 03:47

Simulated: Sep 28, 2001; Lowtax giveth, and Lowtax taketh away.; College Slice

Huckleduck posted:

Quick question about using Swift as a script. I made an XCode project file with the Swift Package Manager. The purpose of the script is to contact a server and download some files, then write those files to disk. This is an async operation, but scripts end whenever they let go of the main thread. I've tried three things, one of which worked.

1. I tried to make a Dispatch Semaphor (a counting one, value of 0) and iterated it in the completion block of my async call in the script. This did not work, somehow the completion block never came back.
2. I tried using Dispatch Group. I made a group, entered the group, all the usual jazz, left the group in the completion block of the script and made a dispatch wait with a timeout. The timeout always gets hit, the completion group never comes back.
3. I made a property called "isDone" outside the function, setting it to false. Inside the async function's completion block I set it to true. Then, I grabbed the current runloop, then made an autorelease pool. In the autorelease pool I have a while loop that does nothing, but it does hold onto the main thread until isDone is true. This actually works.

I realize that #3 here is jank, and in my defense I did #1 and #2 first - I have worked with GCD and am 95% sure I have all the elements in place. Is it not working because of the weirdness of running this script through Terminal?

As others have said, you need to run the main runloop. Create a dispatch source signal handler for SIGINT so if the user presses CTRL+C you can cleanup properly. You don't need to bother freeing memory or anything fancy because the process will die shortly anyway, but it is nice to remove any temporary files, etc.

code:

let source = DispatchSource.makeSignalSource(signal: SIGINT)
source.setEventHandler {
    // Do cleanup, cancel, teardown work here
    print("\nExiting...")
    exit(0)
}
signal(SIGINT, SIG_IGN) //ignore default handler
source.resume()

// Do async work here

// Will never return
RunLoop.main.run()

# ¿ Apr 10, 2017 20:49

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Just one more thing - Swift thread

«‹›4 »