[swift-evolution] [Pitch] Raw mode string literals

[Xiaodi Wu]

On Sat, Nov 25, 2017 at 12:08 AM, Chris Lattner <clattner at nondot.org> wrote:

>
>
> On Nov 24, 2017, at 7:52 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>
> etc.  Even if we don’t have a “default regex” for types, it would still be
>> awesome to be able to write:
>>
>>
>> if case /(let name: [a-zA-Z]+) (let count: Int: [0-9]+)/ =
>> getSomeString() {
>>    print(name, count)
>> }
>>
>> and have that transparently invoke and check the Int?(string) failable
>> initializer.
>>
>
> Yes, these are very interesting options to explore, and you're right that
> if we want to go down this road, then we'd need to imbue regex literals
> with certain "smarts" as opposed to having lenient regex literal parsing
> that entirely defers validation to a concrete regex type conforming to
> ExpressibleByRegularExpressionLiteral.
>
> I don't think it's an all-or-nothing proposition, though, as to whether
> the literal or the conforming type performs the validation. Personally, I
> think one of the strengths of Swift's literals is that they are
> intrinsically untyped and that multiple concrete types are expressible by
> them.
>
>
> Right, but the string literal syntaxes we have (single and multiline) do
> not allow different grammars (e.g. escape sequences) depending on what type
> they are inferred to.  Wouldn’t it be odd if a string literal accepted
> “\x12\u1212\U00001212” when it converts to a "const char *” but accepted
> “\u{12345}” when passed to a bridged Dart API?
>

...And here we come full circle. The original proposal is precisely to have
a different type of string literal that accepts/rejects different escape
sequences. In my initial reply, I wrote that (should raw strings be
sufficiently motivated that some sort of solution is clearly desirable) one
avenue to explore is redesigning literals to allow conforming types to
access the "raw" literal, free of all but the most minimal processing, so
that the type can choose the grammar rather than the literal. In so doing,
we avoid having to hardcode new "flavors" of string literal.

It is precisely in observing these repeated requests for now flavors of
string literals, as well as existing shortcomings of integer and float
literals for supporting BigInt and Decimal types, that leads me to think
that we should exactly allow what you describe as "odd."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171125/4306db10/attachment.html>