Ender.uNF posted:

The book calls out that Swift does not do any automatic conversion, you must explicitly do it. It's under "The Basics", "Integer and Floating-Point Conversion":

quote:

doIt("yes")

func doIt(a:String) {

}

Ender.uNF posted:

error: Use of unresolved identifier 'doIt'


So the compiler isn't smart enough to resolve symbols declared in the same file unless declared in-order?

Dessert Rose posted:

Am I supposed to be able to modify enum values if I pattern-match them?

Plorkyeran posted:

Enums are value types, so you're passing a copy each time you call update. You have to box the enum if you want to pass a reference.

Ender.uNF posted:

Meat Street posted:

Sanity check before I file a radar:

code:

func fibonacci(n: Int) -> Int {
    func fibonacciStep(a: Int, b: Int, n: Int) -> Int {
        if (n > 0) {
            return fibonacciStep(b, a+b, n-1)
        } else {
            return a
        }
    }

    return fibonacciStep(0, 1, n)
}

This should be perfectly legal, right? It crashes Xcode every time as written above, but if I don't nest the functions it works just fine.

e: finally got it to spit out an error instead of crashing:

code:

Playground execution failed: error: Execution was interrupted, reason: EXC_BAD_ACCESS (code=1, address=0x1).
The process has been left at the point where it was interrupted, use "thread return -x" to return to the state before expression evaluation.
* thread #1: tid = 0x4b7f8b, 0x0000000000000001, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x1)
  * frame #0: 0x0000000000000001

Ender.uNF posted:

edit: my rationale is that CoreData already uses exceptions so if you want to interoperate you need to be able to deal with them.

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?

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?

shodanjr_gr posted:

This is an exception-al () writeup. Thank you.

If I'm reading this correctly, this will also handle nested try calls with rethrowing, correct?

Also, does Swift allow C-style typedefs? Those try function signatures look like brainfuck at first glance.

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?

lord funk posted:

May be a dumb question, but is there a possibility of an Xcode Edit >> Refactor >> Convert to Swift... in the future?

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.

Dessert Rose posted:

Okay, but this has the same result:

code:

enum Foo
{
    case Bar(Int)
}

var baz = Foo.Bar(42)
switch (baz)
{
case var .Bar(val):
    val -= 1
}
switch (baz)
{
case var .Bar(val):
    val -= 1
}

Ender.uNF posted:

error: Use of unresolved identifier 'doIt'

So the compiler isn't smart enough to resolve symbols declared in the same file unless declared in-order?

Ender.uNF posted:

Here, have some exception handling in Swift:

Meat Street posted:

It was a design decision of the language to not have exceptions and I doubt they'll double back on that

shodanjr_gr posted:

Also, does Swift allow C-style typedefs? Those try function signatures look like brainfuck at first glance.

Meat Street posted:

rjmccall (or anyone else), I'm curious: do you have any recommendations as far as getting up to speed on the more functional side of things? Obviously it doesn't have to be Swift-specific. Last time I tried Learn You A Haskell it flew over my head, but maybe I should give it another shot now that I have some more concrete motivation

rjmccall posted:

It was crazier during the actual talk, because I actually sprinted through the remaining half-dozen slides, rushing all the content while the staff turned on the music and raised the house lights. We debated what to do for the recording, and I told them to cut there because (1) it is hilariously abrupt and (2) the next fifteen seconds were basically just me stuttering out gibberish anyway while I slowly realized what was happening.

Meat Street, I don't have specific suggestions about learning functional programming, sorry.

Hughlander posted:

Who's the evangelist? I want to send in E-Mail asking that you go back and loop over the slides / remaining slides and give the full presentation as it was designed to be.

lord funk posted:

Are property observers meant to substitute for key value observation in ObjC? It seems to me that they're very local, like having a class observe itself, but not able to be used for MVC coordination the way I've been using KVO.

Ender.uNF posted:

I am not advocating for exceptions, just dealing with the fact that they exist and will be thrown if you're using CoreData.

eschaton posted:

Core Data really shouldn't be throwing an exception for anything that isn't programmer error; if it is, report it as a bug and send me the bug number for followup if you can.

Doctor w-rw-rw- posted:

If programmer error will happen, then it follows that exceptions will happen. I think it was implicit in his statement that if you're using Core Data, you're probably going to misuse it at some point and trigger an exception.

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.

Nipplebox posted:

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