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

[Kevin Ballard]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151212/7443d316/attachment.html>