Swift 2: throwing in initializers?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

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

--
You received this message because you are subscribed to the Google Groups "Swift Language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/swift-language/AE9AA2AB-6115-4826-8518-4D82FA2B93B7%40icloud.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Swift 2: throwing in initializers?

Jens Alfke

On Jun 21, 2015, at 11:29 AM, Alex Hall <[hidden email]> 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

--
You received this message because you are subscribed to the Google Groups "Swift Language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/swift-language/B30BBD24-B428-4FDB-8336-EBE4F0C696BB%40mooseyard.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Swift 2: throwing in initializers?

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: +)


--
You received this message because you are subscribed to the Google Groups "Swift Language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/swift-language/4FDF13EB-9B29-4A8C-8A60-93BB70B69965%40snafu.org.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Swift 2: throwing in initializers?

Chris Lattner
In reply to this post by Alex Hall

> On Jun 21, 2015, at 11:29 AM, Alex Hall <[hidden email]> wrote:
>
> 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!

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

--
You received this message because you are subscribed to the Google Groups "Swift Language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/swift-language/DD381806-D05E-4CB5-9610-0215E7522E30%40apple.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Swift 2: throwing in initializers?

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.
On Jun 24, 2015, at 2:51 PM, Chris Lattner <[hidden email]> wrote:


On Jun 21, 2015, at 11:29 AM, Alex Hall <[hidden email]> wrote:

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!

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


--
Have a great day,
Alex Hall

--
You received this message because you are subscribed to the Google Groups "Swift Language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/swift-language/4C427C0E-5FE3-4840-B9DB-599B5AD2BB6C%40icloud.com.
For more options, visit https://groups.google.com/d/optout.