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

toiletbrush: May 17, 2010

Filburt Shellbach posted:

The Advanced talk was great. I'm glad the syntax mungling examples were tempered by words of caution.

Generics are fantastic. Can't believe the code you guys had on screen for the memoization example. There's a whole class of young programmers who are going to be introduced to FP through Swift.

Yeah watched all the Swift talks and I was pretty blown away by how powerful the language is...I don't really like how 'if let' or in read but apart from that I'm really excited to start doing Swift stuff.

I've got a couple questions I haven't seen asked, sorry if they were already asked and I missed em...

Is Swift going to enable better refactoring support in Xcode? I really, really miss Resharper when doing ObjC dev

Also, I'm writing an iPhone app that makes a lot of use of raw C byte arrays for performance, is there a performant way to allocate and read/write a raw c-style array with Swift, or should I leave that bit in ObjC?

# ¿ Jun 6, 2014 21:02

Adbot: ADBOT LOVES YOU

# ¿ Apr 29, 2024 05:48

toiletbrush: May 17, 2010

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?

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.

I've kinda given up using Swift for my iOS project (just time constraints) so now I'm facing the usual problem of learning about an awesome new PL and really wanting to try it but having no idea what to actually do with it, so I'm burning through a few Project Euler problems in the Playground, and its a joy. Even the numerous problems that are basically variations on 'how many different ways are there to do xyz' are fun because Swift makes writing your own little expressive DSLs and abstractions so easy.

# ¿ Jun 8, 2014 19:18

toiletbrush: May 17, 2010

Possibly stupid swift noob question - how come I can do

code:

for x in someString

but I can't do

code:

someString.map { ... }

# ¿ Apr 29, 2015 09:39

toiletbrush: May 17, 2010

pokeyman posted:

Try map(someString) { ... }

I get that you can do that, it just seems odd to me that you can do all these 'treat a string as an array of characters' operations, but the standard map-reduce syntax doesn't work, and was wondering what the reasons behind that are.

# ¿ Apr 30, 2015 12:04

toiletbrush: May 17, 2010

Yeah that explains it, plus I was really confused...I assumed map() and reduce() where extensions on SequenceType/GeneratorType, rather than just being methods of Array(). Is there any chance of having extensions on protocols in the future?

# ¿ May 1, 2015 10:24

toiletbrush: May 17, 2010

I'm trying to write a lovely stack based language in Swift, and its been great fun so far...are abstract classes/methods planned for Swift at all? What about implicit return values?

# ¿ May 3, 2015 14:37

toiletbrush: May 17, 2010

rjmccall posted:

We've thought about abstract classes/methods, but haven't yet designed them. Is there something you can't do with a class-constrained protocol?

No...I posted that before I realised I should be using an interface! There are definitely circumstances in Obj-C (faked, obvs) and C# where they have been useful though.

quote:

We don't have plans for implicit return values, but I'm curious to know what you're thinking of using them for.

It was just a thought, they sort of show up in closures and I wondered if they might be nice in things like getter methods for var's, but to be honest I was more interested in hearing pro's and con's for having them in a language.

# ¿ May 6, 2015 09:31

toiletbrush: May 17, 2010

This code seems to an exception in the compiler when run at SwiftStub, with "expression was too complex to be solved in reasonable time"

code:

[Int](0...10).map {
    println(String(format:"%02d ", $0 / 2) + ["even","odd"][$0 % 2] + ",")
}

I can't try on a Mac at the moment...is it worth filing a Radar for?

# ¿ May 7, 2015 11:03

toiletbrush: May 17, 2010

rjmccall posted:

In toiletbrush's example, the type-checker has probably decided to try to solve the part of the system that's within the closure before deducing that $0 : Int, and so the complexity is blowing up.

Does that explain why this...

code:

[Int](0...10) {
    println(String(format:"%02d ", $0 / 2) + ["even","odd"][$0 % 2] + ",")
}

...still throws the same exception even though the code is invalid and shouldn't compile?

quote:

(Why are you writing that with map instead of "for i in 0...10 {", anyway?)

The original code that the sample is based on is quite different and was passed an Int array, and also changing the .map to a for/in statement makes compilation succeed, I guess for the reason you mentioned. It looks odd but it was just the simplest reproduction of the error I could write.

# ¿ May 8, 2015 12:31

toiletbrush: May 17, 2010

rjmccall posted:

Well, like I said, the screeners might be jerks. But the team can certainly fix bugs based only on a single file and a command line, and that's how we file them internally.

I think I might have been reporting my bugs to the wrong place, what is the correct product for filing Swift bugs?

# ¿ May 12, 2015 09:25

toiletbrush: May 17, 2010

rjmccall posted:

There's a Swift component.

Oh, it doesn't show up for me...I'm a member of iOS and Mac developer programs, but in the Development section I only get iOS/SDK, OS X/SDK and a couple others but nothing for Swift specifically...

# ¿ May 12, 2015 21:53

toiletbrush: May 17, 2010

Is there a possibility of being able to assign from switch statements? I'm writing a Chip-8 interpreter in Swift, decoding instructions using tuples in a switch statement, but each operator needs to return a value. Right now I set a 'result' value in every case statement, but it would be nice if I could do this...

code:

let result = switch opcode {
            case (0x0, 0x0, 0xe, 0x0) : clearScreen()
            case (0x0, 0x0, 0xe, 0xe) : returnFromSubroutine()
            case (0x1, let n1, let n2, let n3) : jump(decodeThreeBytes(n1, n2: n2, n3: n3))
            case (0x2, let n1, let n2, let n3) : callSubroutine(decodeThreeBytes(n1, n2: n2, n3: n3))
           ......
            case (0x8, let x, let y, 2) : logicallyCombineRegister(x, withRegister: y, operation: .And)
            case (0x8, let x, let y, 3) : logicallyCombineRegister(x, withRegister: y, operation: .Xor)
            default: .Failed(reason: "Invalid instruction ")
}

Does this approach even work?

# ¿ May 24, 2015 15:03

toiletbrush: May 17, 2010

Oh, well thats quite nice isn't it! Thanks!

Edit to add: that works but you have to be explicit about the return type, type inference doesn't seem to be able to figure it out.

I've got another question, would it be possible to have a 'strict' version of typealias that means that the alias is treated as it's own distinct type, rather than just an alias? So something like this would create a compiler error:

code:

typealias Gram = Int

var g = Gram(5)
g = Int(2) // compiler error 'Int' is not convertible to 'Gram'

toiletbrush fucked around with this message at 17:09 on May 26, 2015

# ¿ May 24, 2015 20:13

toiletbrush: May 17, 2010

I got another 'expression was too complex to be solved in reasonable time' compiler exception...

code:

extension Array {
    func sum() -> Int {
        return self.reduce(Int(0)) { Int($0) + Int($1) }
    }
}

I'm gonna file a Radar, but I'd be really interested to hear why it causes issues for type inference?

Also, it compiles fine if I do '$0 as Int', although you don't get any compiler warnings if you pass an array of non-Ints, and instead the app crashes...will this be possible in the future?

# ¿ Jun 3, 2015 13:49

toiletbrush: May 17, 2010

All awesome stuff, althought I thought there was a typo in some docs when it talked about generics in ObjC...until I found out...you added generics to ObjC?!

# ¿ Jun 9, 2015 13:01

toiletbrush: May 17, 2010

I totally love the way that Swift handles errors, but how come the 'throws' keyword comes between the parameters and return type? Its just 'myFailingFunction() throws -> Int { ... }' reads a bit like the function throws an Int...but I guess it makes sense as throwing an exception is sort of a possible return type..

# ¿ Jun 18, 2015 08:45

toiletbrush: May 17, 2010

Is the idea of a 'strict' version of typealias (eg typealias Gram = Int and have the compiler complain if you try to pass an Int to a Gram parameter or add an Int to a Gram) a really bad one for an obvious dumb reason I haven't spotted? If not, is there any way to implement this in Swift, or would it be a possible future feature?

# ¿ Jun 25, 2015 10:53

toiletbrush: May 17, 2010

I'm really enjoying Swift, I still love c# but I'm finding myself wishing I could do swift-thing in C# a lot more than the other way round, which I'm kinda suprised about.

The only thing that I'm still not comfortable with is extensions and generics, using typealiases in code like this:

code:

extension SequenceType where Generator.Element == Int {
    var sum: Int {
        return reduce(0) { $0 + $1 }
    }
}

It makes sense, but seems a bit a odd in the sense that it feels like I'm peering into the class I'm extending a bit too much.

# ¿ Jul 16, 2015 13:05

toiletbrush: May 17, 2010

Is something like 'yield' in the pipeline for Swift? Also assigning to vars directly from switch statements? Someone mentioned before that you can wrap the switch in a closure, but type inference doesn't seem able to infer the type unless you annotate the var you are assigning to, and it feels a bit clunky.

# ¿ Aug 2, 2015 22:41

toiletbrush: May 17, 2010

I came across a surprising compiler confuser just now...

code:

let x = (0..<10).filter { $0 % 3 == 0 }

...compiles, but this doesn't...

code:

let x = (0..<10).filter { $0 % 3 == 0 || $0 % 5 == 0 }

...even if you give 'x' an explicit type.

# ¿ Sep 5, 2015 15:43

toiletbrush: May 17, 2010

Is there any way in Swift to generate a copy of a struct but with one or more values changed? So given a struct like...

code:

struct Thing {
    let blah: String
    let bleh: String
    let oof: Int
}

...and an instance of that struct called myThing you could do...

code:

let myOtherThing = myThing.with { oof = 69 }

I'm trying to write code without any var's, and having to write initializers to support this is the most awkward bit.

# ¿ Feb 25, 2016 12:49

toiletbrush: May 17, 2010

Ah cool...alas I'm being super strict + anal about no var's whatsoever! Purely for a learning exercise.

Do you think it might be a feature for the future?

# ¿ Feb 25, 2016 23:30

toiletbrush: May 17, 2010

rjmccall posted:

Instinctively making everything immutable is definitely a sign of importing philosophy from other languages, though.

That's exactly why I'm doing it here...I got inspired by Eric Lippert's current Ocaml/ZMachine blog to try and write a simple cpu emulation using a similar functional style. I'm just interested in seeing what sort of code and design I end up with if I'm really hardcore/overly explicit about immutability. So far its led to some nice ideas I wouldn't have thought of if I let myself use var, but some of it is awkward as hell...

On a similar note, are there any plans to have a 'strict' version of typealias? Or is it just a bad idea?

# ¿ Mar 3, 2016 14:52

toiletbrush: May 17, 2010

I don't really know Haskell at all but it looks like it, yeah...so having...

code:

typealias Foo = Int

...and passing an Int to a method expecting a Foo would cause a compiler error. I could wrap Int, but I like the cheapness of typealias.

# ¿ Mar 4, 2016 01:25

toiletbrush: May 17, 2010

I've written an extension method on Int called '.asRgbColor' so you can do...

code:

0xfff.asRgbColor

...and get a UIColor back, but calling it like that doesn't compile, I get Expected ';' separator. Weirdly, specifying the number as a decimal, octal or binary works fine - have I done something really silly or is there a bug there?

Edit: I filed a bug, looks like the parser is confused because the 'a' at the start of asRgbColor is valid in a hex string, so it tries to parse it as a floating point hex literal! Changing the var name to toRgbColor fixes the issue...

toiletbrush fucked around with this message at 00:16 on Jun 10, 2016

# ¿ Jun 9, 2016 23:50

toiletbrush: May 17, 2010

I'm trying to build a tiny new Swift 3.0 MacOS app to profile and I'm getting a compiler error...it builds fine without warning running it generally but as soon as I build for profiling I get the following error...

code:

inlinable function call in a function with debug info must have a !dbg location
  %10 = call %swift.type* @_TMaC12TinyRenderer9GameScene() #1
LLVM ERROR: Broken function found, compilation aborted!

Is this a bug or am I doing something stupid? I've tried cleaning etc but no joy

Edit to add: I've deleted code all the way down to just the ViewController stub you get for SpriteKit apps and I still get the error

toiletbrush fucked around with this message at 22:25 on Jul 5, 2016

# ¿ Jul 5, 2016 22:20

toiletbrush: May 17, 2010

There's a big thread going on on the Swift evo mailing list at the moment about making it explicit when implementing a method from a protocol, like...

code:

protocol Poops {
    func poop()
}

class Butt: Poops {
    implement func poop() {...}
}

...or...

code:

class rear end: Poops {
    func Poops.poop() {...}
}

I don't really understand why either of these are a good thing - 'implements' is kinda meaningless by itself as every concrete method 'implements', and the second adds a bunch of noise and boilerplate. Plus, I'm not sure what problem they're trying to solve anyway. What are people's thoughts around here?

# ¿ Sep 21, 2016 10:22

Adbot: ADBOT LOVES YOU

# ¿ Apr 29, 2024 05:48

toiletbrush: May 17, 2010

I'd agree with that ^^

I can see the problems they're trying to avoid, but I think peppering the code with noise is the wrong approach and would be much better solved by better intellisense once Apple have hired all the R# devs to work on XCode.

# ¿ Sep 22, 2016 10:22

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