Skip to content

Allow derive newtype instance for newtypes that use type synonyms #2481

Description

@joshuahhh

My minimal reproduction is

type MyString = String
newtype WrappedString = WrappedString MyString
derive newtype instance semigroupWrappedString :: Semigroup WrappedString

which 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 semigroupWrappedString

even though

newtype WrappedString = WrappedString String
derive newtype instance semigroupWrappedString :: Semigroup WrappedString

compiles without error.

(Originally posted incorrectly to #2416, but this is a different bug.)

Activity

  1. paf31 commented on Dec 14, 2016

    @paf31
    Contributor

    I thought this was the same bug as #2416. How is it different?

  2. joshuahhh commented on Dec 14, 2016

    @joshuahhh
    Author

    @paf31: #2416 is about deriving instances of Newtype for newtypes which use type synonyms, like

    type MyString = String
    newtype WrappedString = WrappedString MyString
    derive instance newtypeWrappedString :: Newtype WrappedString _
    

    #2481 is about deriving newtype instances (via derive newtype instance) of other typeclasses for newtypes which use type synonyms, like

    type MyString = String
    newtype WrappedString = WrappedString MyString
    derive newtype instance semigroupWrappedString :: Semigroup WrappedString
    

    I don't actually know what's going on behind the scenes here, so these may be the same problem at a deeper level.

    But #2416 is, literally speaking, just about a failure to derive instances of capital-N Newtype, so I thought this might be something new.

  3. paf31 commented on Dec 14, 2016

    @paf31
    Contributor

    I thought it was the other way around. Either way, the other issue is #1443, and I think this duplicates one or the other.

  4. garyb commented on Dec 14, 2016

    @garyb
    Member

    The other issue is not #1443, as we discussed before 😛, although once the other issue is fixed, 1443 will probably become a problem too. This one is definitely closer to #1443, and maybe will be fixed by the same thing.

  5. added this to the 1.0 milestone on Dec 21, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions