The future of `enumSum`

[m-bock]

A discussion about the need for enumSum has started in #70 .

We already have a generic version nullarySum which can be used if the tags are not custom. We could extend it with a mapTag option like we have now in sum and sumFlat. Then we could maybe drop/deprecate enumSum.

[garyb]

A variation on nullarySum with mapTag sounds good to me. I started writing about that in the issue I just closed before I noticed you'd already suggested it here. 😄

[m-bock]

Alright, I'll implement it. To be in sync with the other sum codecs this will be adding a nullarySumWith codec that accepts encoding options.

[wclr]

What do you think, is it possible and worth to have more type safe tag mapping feature?

mapTag is just String -> String function, in case we want to have case based convertion it maybe not very safe, for example if we change tag name and forget to update mapTag. Aslo in terms of sematics, encoding settings are meant to be generic for different types, and case based tag name conversion means we turn it into type-specific, so it seems like a workaround.

[m-bock]

From a practical point of view this feature is used with functions like toSnakeCase, toLower, prefixWith....

What do you mean by a more type safe mapping feature, @wclr ?

[garyb]

I'm assuming he's thinking of something where the domain of mapTag only covers the possible inputs. That would probably need to be something more like the other sum codecs, but where you just need to provide string mappings for each case instead:

enumSum "Sample"
  { "Foo": "foolery"
  , "Bar": "bar"
  , "Baz": "bazinga"
  }

I guess being able to do that for sumWith/sumFlatWith could be useful too actually, but I do also see the value in mapTag for the toLower, etc. cases.

[wclr]

Right, as I said mapTag is first of all useful for generic transformations (things like toLower, prefixWith..) and as it is in encoding settings it is meant to be applied to different data types, so I'm not arguing for replacing it.

  { "Foo": "foolery"
  , "Bar": "bar"
  , "Baz": "bazinga"
  }

Something like this would be more safe and type specific, though I'm not sure how it could be incorporated.

Potentially API could be extended with prime functions that would take additional param with tag mappings.

sum'   
 { "Foo": "foolery"
  , "Bar": "bar"
  , "Baz": "bazinga"
  }
  { "Foo": ...
   , "Bar": ...
   , "Baz": ..
  }