Welcome to the Treehouse Community
Want to collaborate on code errors? Have bugs you need feedback on? Looking for an extra set of eyes on your latest project? Get support with fellow developers, designers, and programmers of all backgrounds and skill levels here with the Treehouse Community! While you're at it, check out some resources Treehouse students have shared here.
Looking to learn something new?
Treehouse offers a seven day free trial for new students. Get access to thousands of hours of content and join thousands of Treehouse students and alumni in the community today.
Start your free trial
james gamber
7,727 Pointsoptionals and unwrapping
As Swift is new for me, I noticed that there are no line terminators like period or semicolon. Very good, less is more.
But I also notice that almost every line has either the ? or the ! or some other safeguard code like "if let".
Since this appears in almost every line, then why not make this the default without the ? or the !. I don't see what harm it does to default the language to do all this code protection by default without the programmer having to tell it to do it. Just get rid of all the ? and ! and let the language do all fail checking all the time.
Change the "if let else" to be normal "if else" and then have "if {} fail {} else {} fail{}" where the fail blocks are option and will do nothing as a default if not included. A run time log for development debug should show fail blocks when they occur but are not implemented. These log messages could have a right click to add and open missing but useful fail blocks in editor.
2 Answers
Avi Zolty
2,001 PointsAn optional or unwrapping (the ! or the if let) are only when it's possible to return nil. If this was the standard, then everything that lacked a value would return nil.
I think the confusion is what got me for the longest time-- nil is different to Void.
a function that does not return any value is really func sample() -> Void { //do something }
That way the system knows that it's not expecting any returned value and instead just executing a task. When you put the optional in there it tells it that it SHOULD expect a return, and if the return doesn't work (something goes wrong) rather return "nil" that just crashing.
This gets even more confusing when we get into returning AnyObject or Any or a Type that is defaulted-to because the possible outcomes are all diff subclasses of the same class (and it just assumed the higher class). In this case we need to go so far as to downcast (or have one class act as 'another' class). Which is why we can't just allow a return of "Any" or "Any or Nil" all the time (as this would would require down casting every result always). Hope this clears things up -- and great question :)
james gamber
7,727 PointsNo, you are missing the point. All the things you mention can be still be determined by the compiler for the cases where ? or ! are currently polluting the code.
I have no problems with a function and --> Void, the example you show. Again, you missed the point, that line of code 'func sample() -> Void { //do something }' has no ? or ! in it, which is OK by me.
Casting is always needed when you have the sort of casting issues you mention. A compiler or run time error will quickly show you incorrect object usage in any proper object oriented language.
Just refer back to the original comment for details and maybe you will 'get it'!?