[swift-evolution] Proposal: String literal suffixes for defining types
ilya.nikokoshev at gmail.com
Mon Dec 14 09:56:49 CST 2015
Perhaps there simply should be two different functions, append(char:) and
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
> 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.
> swift-evolution mailing list
> swift-evolution at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution