[swift-evolution] Proposal: String literal suffixes for defining types

Chris Lattner clattner at apple.com
Mon Dec 14 14:48:37 CST 2015 

> On Dec 13, 2015, at 10:31 PM, Alex Gordon via swift-evolution <swift-evolution at swift.org> wrote:
> 
> If Swift is ever going to have multi-line string literals, type affixes should be a prefix and not a suffix. Otherwise the suffix would get lost at the end of a long string.

Now that you mention it, I completely agree, great point.

-Chris

> 
> A nice extra use for affixes is as metadata so that your editor can do syntax highlighting. When I write r"..." in Python (for a raw string), my editor assumes that it is a regex and gives regex-specific highlighting. For SQL, it can only take a guess from the content.
> 
> So I can see re"[a-z0-9]+" and sql"select * from table" adding value, even if the latter is just a pass-through.
> 
> As far as raw strings go, the general feeling in the multi-line strings thread was to either go for single quotes or backticks. If backticks, it could married with this proposal as follows: any prefix + backticks = raw string. e.g.
> 
> r`raw string "quotes"`    // raw string
> re`<a href="[^"]+">`       // raw regex literal
> 
> - Alex
> 
> On Sat, Dec 12, 2015 at 9:19 PM, Kevin Ballard via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> I think you're reading too much into that one example. That was a demonstration of where the ambiguity between Character and UnicodeScalar matters, not the sole reason to use this. Suffice to say, I've hit the ambiguity error between Characters and UnicodeScalars often enough to consider it worth addressing.
>  
> -Kevin
>  
> On Sat, Dec 12, 2015, at 03:26 AM, ilya via swift-evolution wrote:
>> > var s = ""
>> > s.append("c")
>> >
>> > This code looks pretty straightforward,
>>  
>> This looks to me like you're adding a string, which can be done via 
>>  
>> s += "c"
>>  
>> Yes, I know adding a character can theoretically be a bit more performant, but why would that be a consideration for static strings? Compiler should optimize both expressions above to the same result.
>>  
>> > UInt : u // or uint
>> > Int16 : i16
>> > Int32 : i32
>>  
>> I think 
>>  
>> let number = 56i32
>>  
>> is much less readable than 
>>  
>> let number: Int32 = 56
>>  
>> so probably best not to encourage it.
>>  
>>  
>> On Sat, Dec 12, 2015 at 1:48 AM, Marc Knaup via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> Too bad that string literals don't conform to a specific protocol.
>>  
>> This would also be a nice but doesn't work:
>> // StaticString:"An simple string designed to represent text that is 'knowable at compile-time'."
>> extensionStaticString {
>> 
>>     var x: Int {
>>         return123
>>     }
>> }
>> 
>> print("abc".x)
>> 
>>  
>> On Fri, Dec 11, 2015 at 11:38 PM, Joe Groff via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> I was a little disappointed something like this didn't already work:
>>  
>> struct Foo: StringLiteralConvertible { var f: Foo { return self } }
>> struct Bar: StringLiteralConvertible { var b: Bar { return self } }
>>  
>> "x".f // currently a failed lookup in String; could produce a Foo
>> "y".b // same, for Bar
>>  
>> -Joe
>> 
>> > On Dec 10, 2015, at 11:07 AM, Kevin Ballard via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> >
>> > The fact that Swift uses the exact same syntax ("a") for String, Character, and UnicodeScalar can get annoying at times. When unconstrained it's always String, and the only way to disambiguate between the two when used in a context that takes both Character and UnicodeScalar is to explicitly constraint it further, e.g. with `"a" as Character`. A trivial example of this in action is
>> >
>> > var s = ""
>> > s.append("c")
>> >
>> > This code looks pretty straightforward, but it throws an ambiguity error (and the annoying part is, it doesn't actually matter which way it's resolved, the behavior is the same).
>> >
>> > Having to type `"c" as Character` and `"c" as UnicodeScalar` can get pretty annoying if you have to do it a lot. It would be great to reduce this typing a bit.
>> >
>> > My initial proposal here is to introduce string literal suffixes. Let me type something like `"c"c` for a Character and `"c"us` for a UnicodeScalar (and maybe `"c"s` to explicitly mean a String, although that's the default if unconstrained). AFAIK this is not ambiguous with the current syntax, as I don't believe it's ever legal to put an identifier like that after a string.
>> >
>> > Ideally this could be extended by library code with new suffixes. The obvious way to do that is to allow for a new type of "operator" declaration, perhaps something like `literal operator c { type Character }` (where `literal` is a context-sensitive keyword), which declares the suffix and the type (the actual type construction will be done with StringLiteralConvertible, StringInterpolationConvertible, UnicodeScalarLiteralConvertible, or ExtendedGraphemeClusterLiteralConvertible). If the same suffix is declared in two different modules that are imported into the same program, they're unambiguous within their source modules, and within the parent module using the suffix operator will be ambiguous unless further constrained (e.g. similar to using a function that's overloaded on its return type).
>> >
>> > One possible library use for this would be something like `"^\s*foo"r ` for a regular expression (although regular expressions probably also want some sort of "raw" string literal syntax to deal with escapes, but that's orthogonal to this proposal).
>> >
>> > Syntax is up for debate. I picked postfix characters because I believe it's ambiguous and it has precedent, both in C's numeric literals, and in C++11's user-defined literals (although C++11 has a required underscore before the literal, I believe this is just to allow C++11 to define its own new suffixes without ambiguity). This syntax could also work for numeric literals, come to think of it, with the same declaration and using IntegerLiteralConvertible or FloatLiteralConvertible. Heck, it could work for array and dictionary literals too, though that's less likely to be useful.
>> >
>> > FWIW, Playground color and image literals have the form [#Color(colorLiteralRed: 1, blue: 0, green: 0, alpha: 1)#] and [#Image(imageLiteral: "hi.png")#]. These are interesting, but don't solve the original problem (of having to type out the full type name) so this syntax is not appropriate for this feature (but the syntax is fine for what Playgrounds use it for, which is to embed literal colors/images into the source code).
>> >
>> > -Kevin Ballard
>> > _______________________________________________
>> > swift-evolution mailing list
>> > swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> > https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>  
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>  
>>  
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>  
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>  
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> 
>  _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151214/b7e53949/attachment.html>

More information about the swift-evolution mailing list