Raise a CLC/GHC proposal

[hasufell]

Since IsString is a broken interface, I suggest to raise a GHC and CLC proposal (since the class will need to be added to base).

I think the ByteString discussion is enough evidence that there is a problem.

The new OsString/OsPath interface in filepath is another evidence: it will never support IsString and OverloadedStrings.

So we need a new class and a new GHC extension.

I can't say how this will go on GHC steering committee side, but I can assure you my CLC vote will be +1 and I will vehemently promote it.

I don't have any knowledge about an actual implementation, but my guess is it would follow a similar pattern as OverloadedString and just inject class function at string literals?

One concern was that it will require TH and will make it hard to write trustworthy code. I believe @angerman had an idea of an IO-free TH. Maybe that will complement such an extension, but I think it could be proposed regardless.

Wdyt?

[merijn]

I think it's such a great idea, that I already did that almost a decade ago ;)

The entire existence of this library is because I made a "proposal" (well, you know, "an email to the GHC list", because the proposal process hadn't been invented yet). Which was (at the time) rejected as being "unnecessary" and it was suggested I make a library as proof-of-concept to show that anyone would actually want/need something like this.

I think this doesn't/shouldn't need to full power of TH anyway (which was the reason I felt it should be part of GHC), since I think support pure functions returning Maybe or Either covers 98% of all use-cases.

Unfortunately, I don't really have the bandwidth to write well specified proposal at the moment.