Tony Morris

I've never thought about this before. Is it really valid to have a NUL in the middle of a Text?

Yes, \NUL isn't any different than \n or \r. C's null terminated strings (which could be ascii, ansi, utf8...) are encoding layer on top. Pascal had length-annotated slices: no problem. Text is also ptr+offset+length.

And even after knowing and appreciating this, we still can't use QC with pg-simple with minimal friction. Thus, my original comment.

And I still think your record should have non-Text fields. With GeneralizedNewtypeDeriving it's quite handy to generate most of needed instances, and then manually tweak the rest. Also giving domain specific names to text manipulation helpers will help in the long run.

Is this a strong *recommendation*? Can you point me to a largish codebase that has newtypes for most domain specific Texts? I ask because we tried with EmailAddress i our codebase and aren't really happy with how it turned out. Need to learn how to do this.

I newtyped a lot of the text and bytestring values in the work code base. it found a bug and made the type signatures vastly easier to read.

Is there an effective way to deal with the boilerplate that ensues when you want to use regular library functions that don't know about your newtype?

I just write the boilerplate. It's not much and it's clearer than any metaprogramming approach would be. The newtype class in lens is good