UPGRADE YOUR SKILLS: Learn advanced Swift and SwiftUI on Hacking with Swift+! >>

SOLVED: Day 19 Challenge: switch-case-default

Forums > 100 Days of SwiftUI

I have solved the Day 19 challenge, but I have a question:

    var outputTemp: Double? {
        switch toUnit {
        case "Celsius": return inputTempInCelsius!
        case "Fahrenheit": return inputTempInCelsius! * 9 / 5 + 32
        case "Kelvin": return inputTempInCelsius! + 273.15
        default: return nil
        }
    }

Here, toUnit is state-bound to a picker with the three specified values. But the computed property doesn't know that and the Swift compiler complains if I don't have a default case, because "Switch must be exhaustive". So I addd the default case but I don't want to make it return zero, because, well, "zero" is not the same thing as "invalid", and although the default case will never happen, well, what if it does in the future after numerous changes to the app? So I returned nil instead and made my computed property an optional. Is this the best approach? If not, what am I missing?

Thank you in advance.

2      

Keeping it simple, for the level of this challenge and fo rthis particular case, you can eliminate the optional, if you make the celsius calculation the default.

var outputTemp: Double {
    switch toUnit {
    case "Fahrenheit": return inputTempInCelsius! * 9 / 5 + 32
    case "Kelvin": return inputTempInCelsius! + 273.15
    default: return inputTempInCelsius!
    }
}

3      

Farid finds an exhausting puzzle:

...snip.... I don't have a default case, because "Switch must be exhaustive". ...snip...
although the default case will never happen, so I returned nil instead and made my computed property an optional.

Nice approach!

Indeed, zero is not the right value to return if you're provided with an unusual value for toUnit. You applied knowledge from Day 19 about optionals!

Is this the best approach? If not, what am I missing?

Maybe what you forgot is a lesson from Day 3!

See -> Power of enums

Your computed property relies on the value of toUnit. Strings, like toUnit can contain gazillion possible combinations of characters.

Can you refactor a solution where toUnit contains possibilities limited to those you define in an enum? Instead of defining toUnit as a variable that holds a string, what might be a better way to define toUnit ?

Give it a try and tell us how you updated your solution.

Keep coding! Keep asking questions.

3      

@Obelix and @greenamberred Thank you for the excellent responses. I feel like I should've been able to think of these myself if I were less sleep-deprived! But more importantly, this interaction, which was my first time in the forums, really drove home how supportive this community is and was really encouraging. Thank you again sincerely. I just refactored my code using enums, by the way. :) Cheers!

2      

BUILD THE ULTIMATE PORTFOLIO APP Most Swift tutorials help you solve one specific problem, but in my Ultimate Portfolio App series I show you how to get all the best practices into a single app: architecture, testing, performance, accessibility, localization, project organization, and so much more, all while building a SwiftUI app that works on iOS, macOS and watchOS.

Get it on Hacking with Swift+

Sponsor Hacking with Swift and reach the world's largest Swift community!

Archived topic

This topic has been closed due to inactivity, so you can't reply. Please create a new topic if you need to.

All interactions here are governed by our code of conduct.

 
Unknown user

You are not logged in

Log in or create account
 

Link copied to your pasteboard.