Single Quoted Character Literals (Why yes, again)

[johnno1962 (John Holdsworth)]

I think I need to grab the reins and try to wrestle this pitch back on track after some of the digressions yesterday evening. The first thing I want to say is the #1 guiding principle for the implementation from which the proposal is derived is that it is a compile time feature and does not require any new support from the language runtime. As such, new protocols, conformances or types and re-inventing or coming up with a parallel treatment of single Quoted literals is out of the question. This also has the advantage that it restricts the space inside which the proposal can iterate otherwise the degrees of freedom are so great there would be little hope of gathering any consensus. It also re-uses some critical well exercised code.

Taking this approach leaves the implementation with two identities that people seem to fixate on: 'x' + 'y' == "xy" and 'x' + 'y' == 241. The core team touched on the former in their decision noting:

@Ben_Cohen

One concern raised during the review was that because ExpressibleByStringLiteral refines ExpressibleByExtendedGraphemeClusterLiteral, then type context will allow expressions like 'x' + 'y' == "xy". The core team agrees that this is unfortunate and that if these protocols were redesigned, this refinement would not exist. However, this is not considered enough of an issue to justify introducing new protocols to avoid the problem.

I would go further and say this isn't a bug but a feature in that it seems reasonable to me that it should be possible to compose a String as the concatenation of character literals.

Looking at the ExpressibleBy hierarchy enhanced by this pitch and turning it the right way up and underscoring the marker protocols, the following is envisaged:

@_marker _ExpressibleByASCIILiteral
   ↳ @_marker _ExpressibleBySingleQuotedLiteral
     ↳ ExpressibleByUnicodeScalarLiteral
       ↳ ExpressibleByExtendedGraphemeClusterLiteral
         ↳ ExpressibleByStringLiteral

Given how type checking interacts with the protocols and literals the implication of a literal that satisfies one of these protocols is that it also satisfies all those below it. i.e. an ASCIILiteral can be a SingleQuotedLiteral which can be a UnicodeScalarLiteral and so on down to it being valid as a String. Unless we are prepared to revisit how these protocols are applied in the compiler there is nothing you can do about the identity above.

Defining these new marker protocols (which don't really exist outside the compiler and therefore don't affect ABI) allows us to target the integer conformances in a way that was not possible with that previously reviewed implementation and the following issue which was one motivation for separating out the integer conformances is less relevant (though they can still be separated out.)

@Ben_Cohen

This part of the proposal is also not affected by the ABI stability issues relating to backward deployment of conformances.

With regard to the second identity if you introduce the integer conformances 'x' + 'y' == 241 and related absurdities it is only possible to defend this by mentioning C and Java have co-existed with this tenant for decades and it hasn't been reported to be an issue to my knowledge. It's testament to the power of the Swift String model's abstraction that people can no longer see past it.

More than anything else I am interested in keeping this pitch be as limited in scope as possible i.e. practically implied by the existing means literals are type checked. If we open the door to major rethinks of how things work we are lost and will only open the door to increased complexity of the implementation, subtle regressions, loss of consensus and failure to get anything actually delivered.