Remove Elm instance for String data type

[chshersh]

Because of this instance, it's not possible to derive Elm typeclass for newtype wrappers. I see the following error:

    • Overlapping instances for Elm [a]
        arising from the 'deriving' clause of a data type declaration
      Matching instances:
        instance Elm a => Elm [a] -- Defined in ‘Elm.Generic’
        instance [overlapping] Elm String -- Defined in ‘Elm.Generic’
      (The choice depends on the instantiation of ‘a’
       To pick the first instance above, use IncoherentInstances
       when compiling the other instance declarations)
    • When deriving the instance for (Elm (SqlArray a))
   |
11 |       deriving newtype (Eq, ToJSON, Elm)
   |                                     ^^^

[vrom911]

Wouldn't OVERLAPPABLE pragma help here?
I don't mind removing the instance if needed 🙂

[chshersh]

@vrom911 We already have OVERLAPPABLE pragma 🙂 This is needed because we have instance Elm a => Elm [a] and instance Elm String. But for some unknown reason, if I use newtype deriving strategy for wrappers around [a], GHC cannot decide to choose proper instance... The same problem with the swagger library, the library also has similar instances. So it looks like OVERLAPPABLE breaks automatic deriving.

I also think that you shouldn't use String data type anyway, so I'd instead remove this instance to get nicer interface, rather than supporting rare use case using controversial features...

[ShrykeWindgrace]

I guess I am very late to the party, but I think that there are valid use cases for passing a (newtype of) String between Elm and Haskell, most notably base64-encoded binary data.

Anyway, I am ok with manually writing newtype Base64 = Base64 String; data Payload = Payload {userId::Int, signature::Base64}; instance Elm Payload =)