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

«‹›2 »

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

rjmccall posted:

It's not like we're dropping Objective C. We think Swift is a pretty great alternative, and we'd like it to eventually be center of development on the platform, but obviously there's a massive amount of code written in Objective C, and not only do we want to continue supporting that, but we also want to support seamless interoperation with it.

So long as Swift isn't unceremoniously dropped in two years like garbage collection in Objective-C (feel free to comment on that if you want), I'm happy to jump in whole-hog.

Presumably since it's the same runtime and ABI (? or a transparent FFI) one could deploy compiled Swift on to old versions of iOS and OS X?

# ¿ Jun 2, 2014 20:13

Adbot: ADBOT LOVES YOU

# ¿ Apr 28, 2024 20:11

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

Plorkyeran posted:

On the Xcode side of things it'd be nice if the warning about it inferring AnyObject suggested adding a cast rather than explicitly annotating as AnyObject, especially for for-int loops since it wasn't totally obvious I could just cast NSArray to Foo[] in the loop header.

I'm sure you know this already but just in case: file a radar!

# ¿ Jun 3, 2014 01:29

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

tef posted:

- Will there be named versions of .. and ... because i'm poo poo at remembering the difference.

One more dot = one more iteration!

# ¿ Jun 3, 2014 02:15

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

bumnuts posted:

Why is @lazy the only keyword with the @ prefix? Why not just lazy?

There's a ton of attributes with the @ prefix. A list is in the book, in the chapter called "Language Reference", in the section called "Attributes".

# ¿ Jun 4, 2014 00:41

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

The in keyword is just bizarre. Makes no sense to me whatsoever.

# ¿ Jun 5, 2014 19:52

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

Plorkyeran posted:

I'm guessing it's from ML where let x = 5 in ...stuff with x... is how variables are declared.

That makes sense.

I'm still confused about it, just not in Swift

# ¿ Jun 5, 2014 20:50

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

Plorkyeran posted:

Turning off runtime safety checks just to make fast enough code faster is obviously dumb, but sometimes it'll make the difference between being able to use Swift with the checks only enabled in dev builds and having to write the code in something far less safe like C. A certain level of performance is sometimes a hard requirement.

I assume you can turn them off per file, right? So you could write a tiny core that doesn't check anything and only expose it via an interface that does.

# ¿ Jun 7, 2014 00:08

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

Meat Street posted:

It was a design decision of the language to not have exceptions and I doubt they'll double back on that, nor would I use them if they were added, but this does raise (heh) an interesting question: does the Core Data talk this year have anything to say about usage patterns in Swift?

All I remember is it saying "it works, use @NSManaged", nothing about exceptions.

# ¿ Jun 8, 2014 18:07

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

toiletbrush posted:

What is a good alternative to exceptions? They're one area of programming I'm very used to using but most of the arguments about them go a bit over my head.

Conditions sound pretty cool, though I have no actual coding experience with them so I don't know how they hold up in practice. Basically they're like exceptions but you don't have to handle the exception where you catch it. So you don't have to unwind the (whole) stack, though you can if you want.

To my eyes it's vaguely reminiscent of the design of NSProgress, in that you can monitor and affect lower-level functions without directly mucking about. I'm pretty sure you could implement NSProgress on top of conditions.

# ¿ Jun 8, 2014 20:06

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

Ahaha best ending to a session. Nicely done!

# ¿ Jun 9, 2014 05:39

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

eschaton posted:

I mean programmer error in the Cocoa sense; Cocoa exceptions aren't meant to be caught by an app and recovered from, they're meant to be caught by a debugger and prevented.

In other words, "Core Data throws this exception I can't catch in Swift and there's nothing my code can do to prevent it" is properly solved by fixing Core Data not to throw an exception, rather than by letting your app continue with potentially corrupt state.

Of course, if it's because of something an app did (like trying to fire a fault for a deleted object) the solution is to not get into that situation in the first place.

A suitably paranoid app might want to catch a Core Data exception, save some state for recovery, then rethrow. While the conscientious developer is typing up their bug report, their customers keep their data.

I'm rarely so paranoid, but it's not outright ridiculous that an app might want to catch an exception from Core Data.

# ¿ Jun 10, 2014 02:51

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

Nipplebox posted:

I'd be paranoid of writing to disk since Core Data would be in an undefined state.

Well you wouldn't ask a managed object context to save, but you could poke at any managed objects you have hanging around and stuff a plist somewhere (being sure not to fire faults), or grab the contents of a text view.

This doesn't really have much to do with Swift, though. We can take it to the Apple dev thread.

# ¿ Jun 10, 2014 03:21

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

Can we make properties in Swift atomic by default?

:suicide:

actually let's not.

# ¿ Jun 14, 2014 21:33

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

Swift seems so relentlessly practical, I imagine tail call optimization gets a big "who cares" stamp and goes to the back of the line.

# ¿ Jun 22, 2014 07:10

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

ljw1004 posted:

Even if you make the calculation as quick as possible, it looks like you can't get rid of the race condition:

Not to take away from the rest of your post but this excerpt is inevitable if something is to be called a race condition.

# ¿ Jul 21, 2014 20:00

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

What if you put some trivial bit of Swift code in the app?

I've noticed a "copying Swift standard library" compiler step go by during the betas, I wonder if that's not getting triggered for some reason.

# ¿ Sep 10, 2014 07:39

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

fleshweasel posted:

I just got the Xcode 6 public release. I can't make new Cocoa applications with Swift as the language-- only iOS applications. I have googled around a bit and not gotten much. What gives?

OS X gains Swift in Xcode 6.1, which is currently in beta (accessible to paid-up iOS devs and OS X devs). Presumably that'll get a public release alongside Yosemite.

# ¿ Sep 20, 2014 06:04

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

lord funk posted:

How do you write out Swift methods? For example, if I say viewDidLoad() that makes sense. Same with UIImage(named:). But what about UIButton's set image for control state? Is it:

setImage(forState:)
or
setImage(image:forState:)

The documentation uses the Obj-C way of -setImage:forState: which doesn't seem right.

Xcode's symbol menu thinger does
setImage(_:forState:)
which I'm not sure I like. I would say your first option is unacceptable because it looks like the method takes one parameter when it actually takes two.

# ¿ Sep 24, 2014 17:04

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

I have a framework and a test bundle for iOS, both entirely Swift. The framework uses a bridging header to import a CocoaPod for internal use. The framework builds fine on its own. The test bundle links against the framework.

At this point, when I build the test bundle, I get an error compiling the framework's bridging header. I can fix the problem by adding the header search path to the test target, but I don't understand why I need to do this. Why does a target linking a framework need to appease the framework's bridging header? The framework doesn't publicly expose any symbols imported in its bridging header, it's purely internal use. The framework's umbrella header is empty. Am I missing something, or is this just a bug?

I get the same issue with an extension target and with an app target, it's not just a test bundle.

# ¿ Sep 27, 2014 17:39

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

What's the current story for building a framework that mixes Swift and Objective-C and that depends on some CocoaPods to get its work done? All I can come up with is "go gently caress yourself".

Not even blaming anyone (except CocoaPods and my dumbass self), just wondering if anyone's made something similar-sounding actually work.

Can't wait for the tooling to gear up around Swift. Rolling out a new systems language while barely managing annual OS updates must be ridiculous.

# ¿ Oct 1, 2014 06:21

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

Glimm posted:

Might be related to this: https://twitter.com/rustyshelf/status/518205886703996928

Looks like apps recently submitted that use frameworks are crashing on launch.

Yeah twitter's lighting up about it. Here's a devforums thread about it, another one is linked somewhere therein. Some are crashing on embedded frameworks, others with the exact error mentioned by dukerson.

Threads don't mention anything helpful, but you're not alone I guess.

# ¿ Oct 4, 2014 09:43

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

shodanjr_gr posted:

So doesn't Xcode 6 support creating a Swift app for OS X through the new project wizard? I get the option for iOS apps but not for OSX...

Xcode 6.1 brings Swift to OS X. Check the App Store for an update!

If you're using 6.1 already then I dunno.

# ¿ Oct 21, 2014 03:50

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

Open Letter-Driven Development

# ¿ Oct 22, 2014 02:05

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

fleshweasel posted:

"All stored properties of a class instance must be initialized before returning nil from an initializer."

What is the point of this? Why can't I return nil at ANY point during initialization?

My guess is so that the deinitializer can be called cleanly.

# ¿ Oct 24, 2014 00:36

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

lord funk posted:

Not sure if this is a style question or not. Is there any functional difference between referring to properties with self.property vs. just property? I use the former because I think it clarifies that it's a class property and not just a local variable, but I'm wondering if others are doing the same.

It is a style question, and I don't think you meant "class properties". Anyway I do what I do for ivars in Objective-C: skip the self unless it's needed because of shadowing. I feel like I have even more of a leg to stand on for this in Swift, what with all the type inferencing. Though if you put an underscore in your ivar names that works well as a sigil. In conclusion, Libya is a land of contrast.

# ¿ Nov 3, 2014 19:40

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

Morroque posted:

I'm somewhat embarassed to admit it, but I never quite got a good handle on using the Interface Builder -- the old Objective C tutorial book I had wanted to do things the hard by hard-coding everything by setting CGRects and all, but I couldn't get very far with it and the result of that meant I just only ended up with a rather nebulous idea of how View Controllers and everything even worked.

I need to pick up making GUIs in iOS pretty quickly now, but the majority of the tutorials I find are still Objective C oriented. Is the Interface Builder for Swift any different?

Nah it's pretty much identical. Instead of IBAction you use @IBAction. Little stuff like that.

# ¿ Nov 4, 2014 02:54

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

rjmccall posted:

If you mean that you specifically want to extend SomeType?, the answer is that you would write extension SomeType? � but don't bother, that's not supported (yet). Otherwise, you can make it a global function.

I'm skeptical that making a "nil-safe" method in that sense is actually a good idea, though.

I've written something like

code:

if empty(maybeString) {
  // ...
}

func empty(s: String?) -> Bool {
  if let s = s {
    return s.isEmpty
  }
  return true
}

a few times, whereas in Objective-C I'd have taken advantage of messaging nil and written

Objective-C code:

if (maybeString.length == 0)
  // ...

(I'm not presenting this as a particularly compelling use case, mind you, but it's one I've stumbled into.)

# ¿ Nov 9, 2014 12:37

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

lord funk posted:

How would you filter a String to only have upper and lowercase letters? I'm trying to iterate through an NSCharacterSet and use stringByReplacingOccurrencesOfString:withString: to do this, but my brain is failing me.

If you like NSScanner, you could do something like

code:

func keepLetters(s: String) -> String {
  let scanner = NSScanner(string: s)
  let letterSet = NSCharacterSet.letterCharacterSet()
  scanner.charactersToBeSkipped = letterSet.invertedSet
  var components = [String]()
  var onlyLetters: NSString?
  while scanner.scanCharactersFromSet(letterSet, intoString: &onlyLetters) {
    components.append(onlyLetters!)
  }
  return "".join(components)
}

I would not be surprised to learn that an NSRegularExpression does this faster.

# ¿ Nov 13, 2014 04:12

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

Doh004 posted:

No but I can! I always first assume that I'm doing something wrong and don't want to speak outta my rear end about something. I've never done it before but I'll do it tonight

Does it work if you make it a subclass of NSObject?

It's still a bug either way, I just noticed you made a root class and wonder if that triggers something.

# ¿ Dec 4, 2014 22:19

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

This might be a stupid question, but what the hell is a "partial apply forwarder for reabstraction thunk helper"?

# ¿ Dec 15, 2014 15:03

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

Cool, that makes sense.

Are the bad reasons you mention just implementation details at the moment, or is it a consequence of the design? If you can say.

# ¿ Dec 15, 2014 20:34

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

Doh004 posted:

Started new job where our new solution is all Swift. Are we doing something wrong where most of the objects aren't debuggable? I can't do po myObject anymore. Just get a slew of lldb errors. Is it some build configuration setting?

I'll get certain files or parts of certain files where any debugger action just spews errors instead. I can't be arsed to track down the problematic parts, but maybe knowing that you're not alone will help.

# ¿ Feb 5, 2015 04:35

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

I don't know why it feels better to have some insight into why poo poo breaks, but it does. Thanks.

I guess in the "ruthless efficiency" sense the current prioritization works on me: I haven't run away screaming from Swift. If I was leading a team on a new project today, though, there's no way I'd admit Swift into it.

I'll try to remember the missing "public beta" label, it's very easy to forget.

# ¿ Feb 5, 2015 21:48

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

sarehu posted:

Sheesh, talk about software quality at Crapple. They should've implemented Swift in a memory-safe language like Swift.

# ¿ Feb 26, 2015 21:16

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

It's the same basic concept, you just don't get the benefit of helpful framework support or reflection. Write a function that maps your structs into primitives, serialize the primitives as JSON or plists or whatever, and you're all set in that direction.

# ¿ Mar 19, 2015 05:54

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

I think the standard approach is something like make a JSONSerializable protocol and extend your types with implementations of toJSON(). The protocol aids you in making helpers for e.g. collections of JSONSerializable instances.

Also Foundation has kind of a hybrid approach with NSCoder and NSCoding, I wouldn't say it's left entirely up to the serialized objects.

# ¿ Mar 21, 2015 05:34

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

Kallikrates posted:

I don't trust those crazy swift JSON libraries (yet?). In my opinion they just create DSL's around optional unwrapping, and I don't like DSLs.

These were the first thing I thought of when rjmccall mentioned "functional cargo-culting" upthread.

# ¿ Mar 22, 2015 02:13

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

rjmccall posted:

I personally think this is dumb, and several of us would prefer to make it something more consistent like "all parameter names are argument labels by default", but this is where we are right now for complex political reasons.

Would it be worth filing a radar if I feel strongly about particular default argument label schemes?

# ¿ Apr 9, 2015 03:46

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

Try map(someString) { ... }

# ¿ Apr 29, 2015 12:20

Adbot: ADBOT LOVES YOU

# ¿ Apr 28, 2024 20:11

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

dupersaurus posted:

What's the intended use differentiation between tuples and structs? I know that on the extremes, if you have a single function with multiple returns use a tuple, and if you need methods and such use structs. But what about that grey area where the same two bits of information appear in many places -- call it (balls:Int, strikes:Int) -- so writing that tuple signature everywhere gets tedious, but everything that uses the data is external so there's no need for any methods. Do I typealias the tuple, make a struct, or does it not really matter?

Tuples also have the unique ability to be trivially unwrapped into method parameters, so there's that.

There's no shame in a methodless struct.

Other than that, I think it's just a matter of style. If I bother to come up with a name for my typealiased tuple, I'm probably just going to make a struct anyway.

edit: beaten like a named tuple

# ¿ May 27, 2015 03:33

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

«‹›2 »