Consider using descriptive type errors for invalid cast cases

[Martoon-00]

As far as I understand, currently, when I use e.g. intCast incorrectly, I will get Couldn't match type ‘'False’ with ‘'True’ error. It may be not immediately obvious that the conversion method is used incorrectly, and the types between which we convert are not mentioned here so understanding the cause of the failure may take a bit of extra time.

I propose using TypeError to provide better error messages. For instance, it is possible to define some CheckIntSubType wrapper over IsIntSubType that would report Cannot convert a to b error on failure, and then conversion methods can use these Check* constraints instead of ~ 'True.

I'm really happy that I finally found this library, and to me it looks like the most proper solution to the problem; hope it could be polished to final bits of perfection. 🙂

[hvr]

I propose using [`TypeError`](https://hackage.haskell.org/package/base-4.14.0.0/docs/GHC-TypeLits.html#t:TypeError) to provide better error messages. For instance, it is possible to define some `CheckIntSubType` wrapper over `IsIntSubType` that would report `Cannot convert a to b` error on failure, and then conversion methods can use these `Check*` constraints instead of ` ~ 'True`.

That's an intriguing suggestion! int-cast predates the existence of the TypeError facility; I've got other extensions queued up I have prototyped in other libraries to extend/generalise int-cast, and I'll keep TypeError in mind and experiment with it.

[Martoon-00]

Hey @hvr, had you have a chance to look into this proposal?

[andreasabel]

Atm @hvr is the only hackage maintainer of this package, so even if a PR landed, it could not be published.
This would require a hackage takeover.

@Martoon-00, do you want to take over this package? If yes, please carry out the Takeover procedure. I can then give you rights on this repo.

[Martoon-00]

@andreasabel Thanks for bumping on this.

I personally have no opportunity to take handling this package. But maybe I know a person who would...

[lierdakil]

@andreasabel hi, I'm the person in question. While we're here, do you happen to know whether @hvr is available at all, i.e. does it make sense to try to contact them via e-mail first?

[andreasabel]

@andreasabel hi, I'm the person in question. While we're here, do you happen to know whether @hvr is available at all, i.e. does it make sense to try to contact them via e-mail first?

@lierdakil Great to see you are willing to take over this package.

The process should be followed. Can you please open a new issue here where we can track the progress of the takeover with the following steps? (If I open the issues, you cannot tick off the boxes because of lack of permissions.)

• Try to contact the maintainer. Give them reasonable time to respond.
• State your intention to take over the package in a public forum (we recommend the haskell discourse and/or the haskell-cafe). CC the maintainer.
• Wait a while.
• Send an email to the hackage administrators (hackage-admin@haskell.org), with a link to the public email thread.
• The admins will grant you maintenance rights or upload a patched version for you.

You can cut the response period of the first item short (say a week), because it is (by extrapolation of the current interaction pattern) unlikely that @hvr will respond---but you never know.