New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Maybe.unsafe? #215

Closed
evancz opened this Issue Apr 15, 2015 · 5 comments

Comments

Projects
None yet
5 participants
@evancz
Member

evancz commented Apr 15, 2015

With lots of core functions becoming total, it makes sense to consider having a central way to live dangerously.

unsafe : Maybe a -> a

firstNumber =
    unsafe (head numberList)

The unsafe function extracts a value or crashes. But why introduce such a crazy thing?

There are a tiny set of cases where you know it is going to be fine and might want this. For example, imagine you have a Dict and the values are lists. You would never put an empty list in your dictionary, that would be silly, so you know you can always get elements of the list. I have seen this a few times programming in languages like Elm.

The nice part of unsafe is that it makes the risks extremely explicit. Rather than ever creating an unsafe function, you can always return a Maybe and extract it with unsafe. This way, you can search through code for any occurrences of unsafe and quickly identify any risks. It also is a good sign of “maybe you should try to say the same thing a different way?”

This feels similar in spirit to Debug.crash which also makes risks very obvious.

Can you find uses of this in your code? Please share so we can evaluate if it is a good idea!

@haf

This comment has been minimized.

Show comment
Hide comment
@haf

haf Apr 21, 2015

Have you considered adding structural typing on top of lists, to avoid this use case? That way head could be defined totally on the type of non-empty lists.

haf commented Apr 21, 2015

Have you considered adding structural typing on top of lists, to avoid this use case? That way head could be defined totally on the type of non-empty lists.

@lfairy

This comment has been minimized.

Show comment
Hide comment
@lfairy

lfairy Apr 21, 2015

I'd suggest requiring a message as well, so that in the (hopefully rare) case that it fails, we'd get some context as to what happened.

lfairy commented Apr 21, 2015

I'd suggest requiring a message as well, so that in the (hopefully rare) case that it fails, we'd get some context as to what happened.

@nixpulvis

This comment has been minimized.

Show comment
Hide comment
@nixpulvis

nixpulvis Jan 6, 2016

Taking a note from Rust, I've always liked the name expect for this. Unsafe feels weird to me.

nixpulvis commented Jan 6, 2016

Taking a note from Rust, I've always liked the name expect for this. Unsafe feels weird to me.

@jvoigtlaender

This comment has been minimized.

Show comment
Hide comment
@jvoigtlaender

jvoigtlaender Jul 8, 2016

Contributor

Maybe close this? Like https://github.com/elm-lang/core/issues/216, it doesn't seem to have gotten traction.

Contributor

jvoigtlaender commented Jul 8, 2016

Maybe close this? Like https://github.com/elm-lang/core/issues/216, it doesn't seem to have gotten traction.

@evancz

This comment has been minimized.

Show comment
Hide comment
@evancz

evancz Jul 9, 2016

Member

Yeah, I don't think it's necessary given that we made a lot more things return Maybe and it has been pretty fine.

Member

evancz commented Jul 9, 2016

Yeah, I don't think it's necessary given that we made a lot more things return Maybe and it has been pretty fine.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment