Swift 2: throwing in initializers?

[Alex Hall]

Hello list,

I'm playing with Swift 2 in the current beta of Xcode 7. I love the new error-handling, but I ran into something odd yesterday. Here's an example initializer:

class myClass {

var myProp:Int

struct MyErrorsList:ErrorType {

case InvalidNewPropValue

}

init (newPropValue:Int) throws {

guard newPropValue>4 else { throw MyErrorsList.InvalidPropValue }

myProp=newPropValue

}

To me, that looks good. You check that the newPropValue is above 4, and throw your exception if it isn't. If everything is okay, you continue through, making your myProp assignment with a value you know is safe, because it got past the guard statement. However, Xcode doesn't like this. I can't get it to show me the error now, for some reason, but as I recall, Xcode complained that all properties of my class needed to be initialized *before* the guard statements. This strikes me as backwards--would I not want to check the function's arguments for errors before doing anything else? Since the error would stop the class from instantiating anyway, I suppose this ultimately doesn't matter, but I'm curious what the logic behind it is. Does anyone know? Thanks!

--

Have a great day,

Alex Hall

meh...@icloud.com

[Jens Alfke]

On Jun 21, 2015, at 11:29 AM, Alex Hall <meh...@icloud.com> wrote:

Xcode complained that all properties of my class needed to be initialized *before* the guard statements. This strikes me as backwards--would I not want to check the function's arguments for errors before doing anything else?

It’s a current issue/limitation of the Swift compiler. There’s an earlier thread here from about a month ago, where I complained about this (in the context of a failable initializer; this was before WWDC) and Chris Lattner agreed it’s wrong and said they were aware of the problem.

I’m hoping it’ll be fixed soon; has anyone downloaded Xcode 7 beta 2 yet?

—Jens

[Marco S Hyman]

> I’m hoping it’ll be fixed soon; has anyone downloaded Xcode 7 beta 2 yet?

Yes. No issues using it with the code I’ve been playing. I’d mostly
converted that code for the first Beta. The playground, on the other hand...

This is code from the release notes describing some language changes. I
put the code into a new playground. The results sidebar doesn’t match the
edit pane.

1) let x = String.init(5) --->>> (3 times)
2) let stringType = String.self --->>> “123”
3) let y = stringType.init(5)
4) let oneTwoThree = [1, 2, 3].map(String.init).reduce(“”, combine: +)

[Chris Lattner]

> On Jun 21, 2015, at 11:29 AM, Alex Hall <meh...@icloud.com> wrote:
>

Hi Alex,

This is a commonly reported problem, and one we’d like to fix. The compiler currently requires all stored properties to be initialized before failing (with return nil in a failable init) or throwing (in a throws initializer). There are complicated reasons behind this relating to memory safety, and we’d prefer that it be impossible to write code that is memory unsafe in subtle ways.

That said, while we do absolutely want to fix this, it is important to set expectations: it isn’t clear if the work will fit into the schedule for Swift 2.0. There are many bugs that we would like to fix, and fixing bugs and improving quality overall remains a very high priority for us.

-Chris

[Alex Hall]

Thanks for the response. Since throwing will stop the object from being created no matter what, this isn't a big deal, at least as I see it. Keep up the great work; overall, Swift is really nice to use, both typing and reading.