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

[Alex Gordon]

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.

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> 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> 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> 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> 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
> > 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
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> 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
>
>
>
> _______________________________________________
> 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/dc6d3b9e/attachment.html>