I’m getting this as a runtime error, and I’ve iterated through a dozen or so variations on this, getting compile-time errors when expected/reasonable, and compiling fine when I have the types lined up. I see the runtime error only when it’s compiled (the problem there, as I understand it, is that optparse-applicative lets you get through with the type that it can’t handle at runtime). I started with some option parsing code that works with an internal data type, but I need to do that parsing differently for a Text/String value. Lastly, there is the Text/String issue. I tried updating my code to use String for the Parser, but that’s a huge headache… however I did find optparse-text, which I’m exploring now.
The code isn’t public, so sharing that hasn’t been as easy for this (sorry). I have wanted to create a more minimal reproduction, I wasn’t able to do that earlier, but I would like to. I have seen enough weirdness around this I am suspecting a bug here, and a repro is needed to make that more obvious. ATM I guess it is either in optparse or GHC.
That is usually not the case, you then need to have at least one place where you do the “conversion” to the more proper internal types. I have found that especially true with optparse, where it’s harder to keep that conversion contained, and it ends up spilling out to the “command” functions you’ve created.
In my case, there were a bunch more type updates to make and then the conversion. Adding all that code to use String felt like backpeddling… I’d rather be removing code (while improving correctness and features), and not adding an unnecessary conversion.
I’m surprised everyone is so willing to use String, it’s got to go!