Repository navigation
Allow Newtype deriving for newtypes that use type synonyms #2416
Description
Activity
This is the same as the corresponding Generic deriving issue, right?
I don't know if it is exactly, the error is that you're not allowed to declare instances for type synonyms... is that the same reason it fails there?
Oh I see, then no, it's different.
[EDIT: This bug is actually an instance of #2481, a different issue.]
I think I've run into this bug. My minimal reproduction is
type MyString = String newtype WrappedString = WrappedString MyString derive newtype instance semigroupWrappedString :: Semigroup WrappedStringwhich produces the error
No type class instance was found for Data.Semigroup.Semigroup MyString while checking that expression #dict Semigroup has type { append :: WrappedString -> WrappedString -> WrappedString } in value declaration semigroupWrappedStringeven though
newtype WrappedString = WrappedString String derive newtype instance semigroupWrappedString :: Semigroup WrappedStringcompiles without error.
Am I covered by this issue, or is this something different?
(Thanks!)
OK – I just ran into a second, different bug, which actually uses capital-N Newtype deriving. Minimal reproduction is
type MyString = String newtype WrappedString = WrappedString MyString derive instance newtypeWrappedString :: Newtype WrappedString _which produces the error
Type class instances for type synonyms are disallowed. in type class instance Data.Newtype.Newtype WrappedString MyStringeven though
newtype WrappedString = WrappedString String derive instance newtypeWrappedString :: Newtype WrappedString _compiles without error.
I'm guessing this is the bug referred to by this issue, and the bug I posted yesterday is a different one. Is that right?
(Thanks even more!)
The second one is the case that this is for, yep :)
The first one might actually be yet another issue though! As it's for lowercase-n newtype deriving.
Aren't these all the same issue based around when we replace type synonyms?
They fall into that general category yeah. But on the other hand I think we shouldn't normally allow instances for type synonyms, to avoid confusion. So we want them to be desugared for deriving, but not for a hand written instance.
Just hit the same thing (https://groups.google.com/forum/#!topic/purescript/HG7uiRChNhE). I suppose the same argument as why instances for functionally-dependent record types are allowed would apply to type synonyms?
