3 ms·

It's a standard practice in functional languages: https://en.wikipedia.org/wiki/Unit_type https://en.wikipedia.org/wiki/Unit_type

fuzztester 2y ago
That sounds like those corporate types who brush off any complaints by users, by saying "that is corporate policy" :) #sorrycouldntresist But seriously, according to that link, it seems to me like the zero or empty type is more suitable. But I am not a PL or type theory expert.
- saithound 2y ago
  > But seriously, according to that link, it seems to me like the zero or empty type is more suitable. That's a bit different. The empty type is only suitable for functions that never return (e.g. loop infinitely, crash the program). The type checker will prevent functions that have the empty type as a return type from returning.
  - akdas 2y ago
    To expand on this: the "unit" here represents the number of possible values that can be returned. The confusion is probably because "empty" can mean two things: - What's inside the returned value. That may be why the parent suggested empty for the unit type. But that's now what "unit" means in the common parlance. - How many possible values can be returned. Never returning means the function has zero possible return values.
- lmm 2y ago
  It's a one type, not a zero type - the function does return and it always returns the same thing. It makes this kind of function more normal and regular - you can say that functions always return 1 value, and then it means you don't have to special-case void functions (which is a problem you have to work around in e.g. C++ templating), you can do things like put the return value of the function in a variable and then use it for something since it's just a normal value (which matters if you want to write e.g. a generic compose function that runs a bunch of functions in, IDK, a database transaction or something).
- 1-more 2y ago
  You've gotten some great answers but lemme add another thing: The zero type is useful for things that should not happen that you can prevent at compile time, while the unit type is nice for things that can only happen one way. In Elm (a functional language for making web UIs), you might use the unit type for a lazy view function. If and only if some condition is true, call a view function to render some stuff into your DOM tree as in the function viewIfLazy [0]. There's only one way to call that view function, so let's call it with the unit type. Now, what about using the Never type (a type with no members that can be instantiated at runtime [1]) to do accessibility? In Elm, your DOM elements have type `Html msg` where msg is a type _parameter_ for your actual message type that makes your app update itself. Usually you create that type like `type Message = UpdatedTheFooCounter Int | UpdatedTheNameInput String | ClickedTheBlahButton` something like that. Then the type on your inputs and buttons will be `Html Message` (read as "Html of Message" or even "Html parameterized by Message"). Well, it's bad a11y practice to have onclick events attached to divs and spans and things that aren't buttons, generally. So you can give your divs type `Html Never` and then if you try to attach an onclick event to them, you find that you can't at compile time, because the members of the type Message are not members of the type `Never`. tesk9/accessible-html is a package that enforces that [2] (I kind of simplified how it does that because I'm deep enough in the weeds already). [0] https://github.com/elm-community/html-extra/blob/0b8fc70752c9120b6ef997976855f3fde502de26/src/Html/Extra.elm#L65-L84 https://github.com/elm-community/html-extra/blob/0b8fc70752c... [1] https://package.elm-lang.org/packages/elm/core/latest/Basics#Never https://package.elm-lang.org/packages/elm/core/latest/Basics... also has a simpler example now that I think of it. [2] https://github.com/tesk9/accessible-html/blob/master/src/Accessibility.elm#L603-L608 https://github.com/tesk9/accessible-html/blob/master/src/Acc...

fuzztester 2y ago

That sounds like those corporate types who brush off any complaints by users, by saying "that is corporate policy" :) #sorrycouldntresist But seriously, according to that link, it seems to me like the zero or empty type is more suitable. But I am not a PL or type theory expert.

saithound 2y ago
> But seriously, according to that link, it seems to me like the zero or empty type is more suitable. That's a bit different. The empty type is only suitable for functions that never return (e.g. loop infinitely, crash the program). The type checker will prevent functions that have the empty type as a return type from returning.
- akdas 2y ago
  To expand on this: the "unit" here represents the number of possible values that can be returned. The confusion is probably because "empty" can mean two things: - What's inside the returned value. That may be why the parent suggested empty for the unit type. But that's now what "unit" means in the common parlance. - How many possible values can be returned. Never returning means the function has zero possible return values.
lmm 2y ago
It's a one type, not a zero type - the function does return and it always returns the same thing. It makes this kind of function more normal and regular - you can say that functions always return 1 value, and then it means you don't have to special-case void functions (which is a problem you have to work around in e.g. C++ templating), you can do things like put the return value of the function in a variable and then use it for something since it's just a normal value (which matters if you want to write e.g. a generic compose function that runs a bunch of functions in, IDK, a database transaction or something).
1-more 2y ago
You've gotten some great answers but lemme add another thing: The zero type is useful for things that should not happen that you can prevent at compile time, while the unit type is nice for things that can only happen one way. In Elm (a functional language for making web UIs), you might use the unit type for a lazy view function. If and only if some condition is true, call a view function to render some stuff into your DOM tree as in the function viewIfLazy [0]. There's only one way to call that view function, so let's call it with the unit type. Now, what about using the Never type (a type with no members that can be instantiated at runtime [1]) to do accessibility? In Elm, your DOM elements have type `Html msg` where msg is a type _parameter_ for your actual message type that makes your app update itself. Usually you create that type like `type Message = UpdatedTheFooCounter Int | UpdatedTheNameInput String | ClickedTheBlahButton` something like that. Then the type on your inputs and buttons will be `Html Message` (read as "Html of Message" or even "Html parameterized by Message"). Well, it's bad a11y practice to have onclick events attached to divs and spans and things that aren't buttons, generally. So you can give your divs type `Html Never` and then if you try to attach an onclick event to them, you find that you can't at compile time, because the members of the type Message are not members of the type `Never`. tesk9/accessible-html is a package that enforces that [2] (I kind of simplified how it does that because I'm deep enough in the weeds already). [0] https://github.com/elm-community/html-extra/blob/0b8fc70752c9120b6ef997976855f3fde502de26/src/Html/Extra.elm#L65-L84 https://github.com/elm-community/html-extra/blob/0b8fc70752c... [1] https://package.elm-lang.org/packages/elm/core/latest/Basics#Never https://package.elm-lang.org/packages/elm/core/latest/Basics... also has a simpler example now that I think of it. [2] https://github.com/tesk9/accessible-html/blob/master/src/Accessibility.elm#L603-L608 https://github.com/tesk9/accessible-html/blob/master/src/Acc...