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

[ilya]

Perhaps there simply should be two different functions, append(char:) and
append(unicode:)
On Mon, Dec 14, 2015 at 18:46 Martin Kühl <swift-evolution at swift.org> wrote:

> On 11 December 2015 at 06:52, Chris Lattner via swift-evolution
> <swift-evolution at swift.org> wrote:
> >
> >> 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.
> >
> > In principle you should also be able to say “s.append(Character(“c”))”
> but I agree that isn’t much better.
>
> You can also write
>
>     s.append(c("c"))
>
> as long as you have a `typealias c = Character` in scope, and
> typealiases can be block-scoped.
>
> Of course, whether that helps depends on where and how you encounter
> the ambiguity.
>
> -Martin
> _______________________________________________
> 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/e4658d5b/attachment.html>