Maybe: destruct vs withDefault + map

Learn
1

I find myself writing my own version of destruct in my elm projects, typically with map and withDefault.

I was just wondering why it is considered an ‘internal’ function in the Maybe module as it would replace many of my withDefault usages.

Cheers

2

Is destruct the same as unwrap?

https://package.elm-lang.org/packages/elm-community/maybe-extra/latest/Maybe-Extra#unwrap

3

Yes, the implementation is identical.

4

I see. I also got curious about it. Maybe you can file an issue in the bug tracker: Issues · elm/core · GitHub

5

That was my initial idea :slight_smile: however I figured I would be replied with:

We are fairly conservative about adding new functions to core libraries. If you want to augment the List or Array library, we recommend creating small packages called list-extras or array-extras that have all the features you want. There are already several such packages maintained at the Elm Community organization that welcome contributions in the form of pull requests.

Long term, we will set up a process to review *-extras packages to move stuff into core. By going through packages, it will be much easier to assess whether a function is pleasant and useful in practice before committing to it in the core libraries.

(core/.github/CONTRIBUTING.md at 65cea00afa0de03d7dda0487d964a305fc3d58e3 · elm/core · GitHub)

I don’t know if / how the review process is conducted it would be great if we could vote for the functions then.

Thanks for pointing out the maybe-extra though.

6

Evan decides on what goes in the core libraries based on his understanding of the future of Elm and his taste on APIs (which is amazing btw). Much of the delightfulness of Elm is due to his careful consideration of the long term consequences of various decisions. This careful consideration is why Elm is also a lot more conservative than some people like it to be.

In the case of including some function into the core library, once it is there it cannot be taken out without breaking people’s code. One of the arguments against its inclusion is the fact that using it might mask improper data modeling. Consider the fact that the last commit to the Maybe module is a note to warn about overuse of withDefault:

Note: This can be overused! Many cases are better handled by a case
expression. And if you end up using withDefault a lot, it can be a good sign
that a [custom type][ct] will clean your code up quite a bit!

It is this kind of hints that guide people to better code.

1 Like
7

Especially using map + withDefault with a lambda for map is an antipattern IMO.

-- Meh
x =
    something
        |> Maybe.map
            (\foo ->
                bar foo (foo + 1)
            )
        |> Maybe.withDefault 0


-- Better!
y =
    case something of
        Just foo ->
            bar foo (foo + 1)

        Nothing ->
            0
7 Likes
8

Also the documentation says that the deafult is always calculate using unwrap, but it is not calculated using case

9

I don’t follow. What are you saying?

10

This can’t be said enough.

1 Like
11

I don’t follow. What are you saying?

If this question is for me: In the Meh example, the default is a 0. But if that was a function, it would have been calculated even if not used.

In the Better! example instead the default function would have been calculated only if needed.

1 Like
12

Thanks, now it is clear, and helpful!

1 Like
13

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.