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

[Kelvin Ma]

aren’t all literals evaluated at compile time?

On Thu, Nov 23, 2017 at 6:07 PM, Tony Allevato <tony.allevato at gmail.com>
wrote:

> This could be solved by extending the existing string literal handling and
> letting type inference do the rest. The real problem here is that
> `UInt8(ascii: X)` is annoying to write when you're dealing with a large
> amount of low-level data.
>
> If UInt8 conformed to ExpressibleByUnicodeScalarLiteral, you could get
> most of the way there—you'd just have to have it fail at runtime for
> anything outside 0...127. But then you could write `let c: UInt8 = "x"` and
> it would just work.
>
> Failing at runtime is undesirable though, so you could take it further and
> add an ExpressibleByASCIILiteral protocol which would be known to the
> compiler, and it would emit an error at compile time if the literal wasn't
> a single ASCII character (like it does today for Character).
>
> One of the things I think is really elegant about Swift is that string
> literals are untyped by themselves and take on an appropriate type based on
> the context they're used in. Handling different kinds of strings should
> leverage and extend that mechanism, not add new syntax.
>
>
> On Thu, Nov 23, 2017 at 2:43 PM Kelvin Ma <kelvin13ma at gmail.com> wrote:
>
>> On Thu, Nov 23, 2017 at 3:47 PM, Tony Allevato via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>>>
>>>
>>> On Thu, Nov 23, 2017 at 12:21 PM Xiaodi Wu via swift-evolution <
>>> swift-evolution at swift.org> wrote:
>>>
>>>> On Thu, Nov 23, 2017 at 2:14 PM, John Holdsworth via swift-evolution <
>>>> swift-evolution at swift.org> wrote:
>>>>
>>>>> I’m beginning to wish I hadn’t tied this proposal so strongly to
>>>>> regular expressions!
>>>>> It is indeed the wrong motivation. Even as a ten year veteran of Perl
>>>>> development
>>>>> I’m not sure we want to bake it into the language quite so tightly
>>>>> (isn’t a part of
>>>>> Foundation?) What would /regex/ represent - an instance of
>>>>> NSRegularExpression?
>>>>> Would the flags be pattern options or matching options? This is a
>>>>> whole other debate.
>>>>>
>>>>> For me the focus of raw strings was a sort of super-literal literal
>>>>> which has many
>>>>> applications. The r”literal” syntax has a precedent in Python and
>>>>> there seemed
>>>>> to be a syntactic gap that could be occupied but perhaps there are
>>>>> other alternatives
>>>>> we could discuss. It would be a shame to see ‘quoted strings’ be used
>>>>> for this however.
>>>>> I still live in hope one day it will be used for single character
>>>>> UNICODE values.
>>>>>
>>>>> Since what passes for a single character changes by Unicode
>>>> revision--such as whenever they get around to enumerating the permitted
>>>> modifying attributes of the poop emoji--it is quite impossible (and Swift's
>>>> `Character` doesn't attempt to) to enforce single-characterness at compile
>>>> time. We should put any such notions to rest up front.
>>>>
>>>
>>> Unless I'm misunderstanding you here, I don't think that's true: writing
>>> something like `let c: Character = "ab"` is definitely a compile-time
>>> error: https://gist.github.com/allevato/ae267e2aaaa7939d6233d66a87b48fc0
>>>
>>> To the original point though, I don't think Swift needs to use single
>>> quotes for single characters (or single scalars). Type inference already
>>> infers Characters from single-character String literals in contexts where a
>>> Character is expected, and the only time you need to be explicit is if
>>> you're trying to resolve an overload or initialize a variable by itself.
>>> Using single quotes to avoid writing "as Character" would feel like a waste.
>>>
>>
>> i still think single quotes should be used as an alternate literal for
>> UInt8, like char. there’s a lot of cases where you’re working with
>> low-level 8-bit ASCII data and both String and Character and Unicode.Scalar
>> are inappropriate, and typing out hex literals makes code *less* readable.
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171123/c04860c2/attachment.html>