Hi Hécate and David,

I'm in support of this proposal. And the module name "Data.Newtype" sounds good to me 👍

I specifically like the "un" function because it helps to reduce unnecessary boilerplate. If you have a newtype, it's convenient to specify an unwrapping function, e.g.

newtype Size = Size
    { unSize :: Int
    }

But then, it becomes awkward in two scenarios:

1. When newtypes are long, e.g. "PasswordHash".
2. When you rename newtypes, you also need to rename the unwrapping function. While renaming the constructor makes total sense to me, because you want to be explicit in what particular newtype you wrap your values, renaming the unwrapping function looks to me like maintaining the unnecessary boilerplate.

Type inference is a valid concern, but those functions are opt-in, and if people are worried about type inference, they can use type applications or good old record fields. Also, the order of type variables for the implementations from "Relude" is optimized for usage with "TypeApplications", so it's quite convenient to wrap and unwrap newtypes.

Best regards,
Dmitrii

On Wed, 11 Nov 2020 at 10:01, Hécate <hecate@glitchbra.in> wrote:

Do you think that they will produce unwanted inference even with -XTypeApplications?

Le 11/11/2020 à 08:42, David Feuer a écrit :
For the most part, I oppose adding these to base. I'm most sympathetic to adding (.#) and (#.), originally from the profunctors package, as they seem to pop up quite a lot. For the rest, inference can be a real problem. coercible-utils goes to quite a lot of trouble to make these functions reasonably usable, but I don't think we want that sort of machinery in `base`. 

On Tue, Nov 10, 2020, 8:23 AM Hécate <hecate@glitchbra.in> wrote:

Hello, CLC and haskell-libraries,

I am opening a proposal process to consider the integration of several helper functions in `base`, operating on Newtypes, and all based on `coerce`.

My motivations are that we ought to provide a minimum set of tools in order to work effectively with one of our most beloved and ubiquitous language features.

Now, these functions that I am about to present to you all do not come out of nowhere. They have been integrated to Kowainik's alternative prelude "Relude", and seem
to have found their use amongst their users, me included.
Their documentation can be found here => https://hackage.haskell.org/package/relude-0.7.0.0/docs/Relude-Extra-Newtype.html
but I am reproducing them below for convenience:

---
un :: forall a n. Coercible a n => n -> a

Unwraps value from newtype.

```
>>> newtype Size = Size Int deriving Show
>>> un @Int (Size 5)
5
>>> un (Size 5) == length ['a', 'x', 'b']
False
```

---
wrap :: forall n a. Coercible a n => a -> n

Wraps value to newtype. Behaves exactly as 'un' but has more meaningful name in case you need to convert some value to newtype.

```
>>> newtype Flag = Flag Bool deriving (Show, Eq)
>>> wrap False == Flag True
False
```

---
under :: forall n a. Coercible a n => (n -> n) -> a -> a

Applies function to the content of newtype. This function is not supposed to be used on newtypes that are created with the help of smart constructors.

```
>>> newtype Foo = Foo Bool deriving Show
>>> under not (Foo True)
Foo False
>>> newtype Bar = Bar String deriving Show
>>> under (filter (== 'a')) (Bar "abacaba")
Bar "aaaa"
```

As well as the coerced composition operator:

(#.) :: Coercible b c => (b -> c) -> (a -> b) -> (a -> c)
(#.) _f = coerce
{-# INLINE (#.) #-}

Which currently lives in https://hackage.haskell.org/package/base-4.14.0.0/docs/src/Data.Functor.Utils.html#%23 but is not exported.


Regarding the location of these functions, I either see them living in their own "Data.Newtype", or they could join Data.Coerce.
I would personally create a new module as to avoid "polluting" Data.Coerce with non-class functions, but this is my personal preference.


Thank you for reading.

-- 
Hécate ✨
🐦: @TechnoEmpress
IRC: Uniaika
WWW: https://glitchbra.in
RUN: BSD
_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
-- 
Hécate ✨
🐦: @TechnoEmpress
IRC: Uniaika
WWW: https://glitchbra.in
RUN: BSD
_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries