Is there a legitimate reason for `never`

[Philipp_Krueger]

@turboMaCk

That’s correct solution indeed but I think once can still argue that in this case you can get away without Never and use unit type like () , {} or type Unit = Unit in this case.

Can you argue that? What if you want to write a function with the signature Error () -> String (using Unit instead of Never) that renders errors. How do you handle the CustomError ()? Generate an empty string? I guess you’d be losing lots of compiler guarantees there.

---

@MartinS

Another use case for Never is with phantom types.

type Point coordinateSystem = Point Float Float

type WorldCoordinate = WorldCoordinate Never

type ScreenCoordinate = ScreenCoordinate Never

playerStartPos : Point WorldCoordinate
playerStartPos = Point 2 3

healthBarPos : Point ScreenCoordinate
healthBarPos = Point 200 10

Here I’ve defined Point that uses a type parameter to make sure I don’t mix up different coordinate systems. I don’t actually want to create an instance of these coordinate systems though, they are just being used as phantom types. So to prevent accidentally creating them I add Never to their constructor.

This is kind of off-topic, but I usually don’t use Never to define my Phantom type parameter values. This has the advantage that I can specify what coordinate system I generate events for explicitly, like this:

type ScreenCoordinate = ScreenCoordinate

type ElementCoordinate = ElementCoordinate

onMouseDown : coordinateSystem -> (Point coordinateSystem -> msg) -> Attribute msg
onMouseDown _ produceMsg = ...

-- used like this
div
    [ class "main-content"
    , onMouseDown ScreenCoordinate ClickMain
    , style "position" "relative"
    ]
    [ div
        [ class "positioned-element"
        , style "position" "absolute"
        , style "top" model.elementY
        , onMouseDown ElementCoordinate ClickElement
        ]
        []
    ]

[turboMaCk]

@Philipp_Krueger

Can you argue that? What if you want to write a function with the signature Error () -> String (using Unit instead of Never ) that renders errors. How do you handle the CustomError () ? Generate an empty string? I guess you’d be losing lots of compiler guarantees there.

Yes you would loose compiler guarantees because 1 /= 0 but you loose compiler guarantees with original example as described here as well. Anyway, if you assume nothing will ever construct that unit type you pretty much don’t care what you put into that brach. It doesn’t even have to an string, you can do infinit recursion.

@Janiczek

BTW yeah this algebraic way of looking at types is helpful.
Another description: Types as Sets · An Introduction to Elm

Ah cool! I didn’t know elm docs include this appendix now, that is very helpful indeed.

@Janiczek

By your description it seems like the endpoints that have no custom errors (0) still fall into the 0 --> Never category.

yes definitely that why said it’s correct. The usage of unit in its place is just a possible workaround which is less precise but might be potentially argued as good enough solution if one wants to crate case for removing Never type (which I personally don’t think is a good idea). I think this is why the algebraic intuition is the most compelling as it’s easy to illustrate that 0 is neither variable nor 1

[miniBill]

msg identity will just explode at runtime, so it doesn’t really construct anything…