# SE-0243: Codepoint and Character Literals

**URL:** <https://forums.swift.org/t/se-0243-codepoint-and-character-literals/21188>\
**Category:** Proposal Reviews\
**Created:** [March 4, 2019, 3:45pm UTC](https://forums.swift.org/t/se-0243-codepoint-and-character-literals/21188 "2019-03-04T15:45:06Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![ben-cohen](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/ben-cohen/32/296_2.png) [@ben-cohen](https://forums.swift.org/u/ben-cohen)\
**Post date:** [March 4, 2019, 3:45pm UTC](https://forums.swift.org/t/se-0243-codepoint-and-character-literals/21188/1 "2019-03-04T15:45:06Z")

</div>

Hi Swift Community,

The review of [SE-0243: Codepoint and Character Literals](https://github.com/apple/swift-evolution/blob/master/proposals/0243-codepoint-and-character-literals.md) begins now and runs through March 12, 2019.

Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to me as the review manager via [email](mailto:ben_cohen@apple.com) or direct message on the forums. If you send me email, please put "SE-0243" somewhere in the subject line.

**What goes into a review of a proposal?**

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift.

When reviewing a proposal, here are some questions to consider:

- What is your evaluation of the proposal?

- Is the problem being addressed significant enough to warrant a change to Swift?

- Does this proposal fit well with the feel and direction of Swift?

- If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

- How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Thank you for contributing to Swift!

Ben Cohen  
Review Manager

---

<div class="post-metadata">

**Author:** ![allevato](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/allevato/32/385_2.png) [@allevato](https://forums.swift.org/u/allevato)\
**Post date:** [March 4, 2019, 4:05pm UTC](https://forums.swift.org/t/se-0243-codepoint-and-character-literals/21188/2 "2019-03-04T16:05:25Z")

</div>

> [@ben-cohen](#):
>
> - What is your evaluation of the proposal?

Finally! Let's get this merged.

> [@ben-cohen](#):
>
> - Is the problem being addressed significant enough to warrant a change to Swift?

Yes. This feature will be a boon to anyone doing C interop, textual parsing, or working with other low-level data formats. The current `UInt8(ascii:)` initializer is a pain to type and decreases the readability of code. Furthermore, this lets us finally represent single `Character`s conveniently without explicitly typing or `as`-casting them.

> [@ben-cohen](#):
>
> - Does this proposal fit well with the feel and direction of Swift?

100%. I'm bummed that we can't get the conformances in automatically, but I understand that's a limitation of ABI stability right now and this is still a step in the right direction.

> [@ben-cohen](#):
>
> - If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

This fits nicely with how character literals are handled in many languages similar to Swift, so users will find it natural, and the compile-time validation fits perfectly.

> [@ben-cohen](#):
>
> - How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Read and participated in various threads about the issue on the forum.

---

<div class="post-metadata">

**Author:** ![Nevin](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/nevin/32/617_2.png) [@Nevin](https://forums.swift.org/u/Nevin)\
**Post date:** [March 4, 2019, 4:17pm UTC](https://forums.swift.org/t/se-0243-codepoint-and-character-literals/21188/3 "2019-03-04T16:17:26Z")

</div>

Do I understand the proposal correctly here?:

A new syntax is introduced for single-quoted character literals.

No new literal-expressible protocol is added. Instead, the existing unicode-scalar and extended-grapheme-cluster literal protocols are used.

The default type of a single-quoted character literal is `Character`.

Since `String` conforms to `ExpressibleByExtendedGraphemeClusterLiteral`, a single-quoted character literal can be assigned to a `String`:

```swift
let s: String = 'ü'

```

It is possible to extend the standard-library integer types (`UInt8`, `Int`, etc.) with conformance to `ExpressibleByUnicodeScalarLiteral`. Doing so will allow the assignment of a single-quoted ASCII character literal to an integer:

```swift
let n: UInt8 = '*'

```

This is checked at compile time to ensure the literal is in the ASCII range (0–127). The double-quoted syntax does not work for integers.

The existing double-quoted syntax for unicode-scalar and extended-grapheme-cluster literals is deprecated. In a future version of Swift, we can expect that syntax to be removed. When that happens, it will no longer work.

Is that correct? Did I miss anything?

---

<div class="post-metadata">

**Author:** ![johnno1962](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/johnno1962/32/6805_2.png) [@johnno1962](https://forums.swift.org/u/johnno1962)\
**Post date:** [March 4, 2019, 4:26pm UTC](https://forums.swift.org/t/se-0243-codepoint-and-character-literals/21188/4 "2019-03-04T16:26:00Z")

</div>

Thanks @Nevin, That's a very good summary of the cruxes of it.

---

<div class="post-metadata">

**Author:** ![Nevin](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/nevin/32/617_2.png) [@Nevin](https://forums.swift.org/u/Nevin)\
**Post date:** [March 4, 2019, 4:51pm UTC](https://forums.swift.org/t/se-0243-codepoint-and-character-literals/21188/5 "2019-03-04T16:51:38Z")

</div>

Review:

• I think `String` should _not_ be expressible by a single-quoted literal, only a double-quoted literal.

• It is not clear to me why integers are restricted to being represented by ASCII characters only. Every Unicode scalar has a unique integer value, which is already available in Swift at runtime:

```swift
let x: Unicode.Scalar = "∫"
let n: UInt32 = x.value
print(n) // 8747

```

It seems straightforward to make this available at compile-time through the literal syntax being proposed.

• • •

In light of the ABI concerns regarding retroactive conformance of integer types to the `ExpressibleByUnicodeScalarLiteral` protocol, perhaps another possibility should be considered:

We currently have a scenario where double-quoted literals can be interpreted through any of three different `ExpressibleBy___Literal` protocols: `String`, `UnicodeScalar`, and `ExtendedGraphemeCluster`. Evidently, there is no problem with the same syntax being used for multiple kinds of literals.

We also have four different syntaxes for integer literals: decimal, hexadecimal (`0x`), binary (`0b`), and octal (`0o`). Thus there is also apparently no problem with multiple syntaxes for the same kind of literal.

Therefore, perhaps we should make single-quoted characters also be valid \*integer\* literals. Instead of trying to shoehorn integer types into accepting `UnicodeScalar` literals, we could simply make the compiler recognize single-quoted characters as another way to spell integer literals.

Then there is no ABI concern, and in fact no new conformance to add at all.

---

<div class="post-metadata">

**Author:** ![jrose](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jrose/32/408_2.png) [@jrose](https://forums.swift.org/u/jrose)\
**Post date:** [March 4, 2019, 4:58pm UTC](https://forums.swift.org/t/se-0243-codepoint-and-character-literals/21188/6 "2019-03-04T16:58:16Z")

</div>

Small note: please don't use the term "retroactive conformances" for "conformances added in a compatible ABI version". For better or worse, we're already using it for "conformances added in a separate module from either the type or the protocol", and the issues around the two are not the same. Maybe "version-dependent conformances" or "backwards-deployable conformances" (I'm not sure which meaning's being used here).

* * *

I am weakly in favor of the proposal except for the deprecation part, because I don't want to assume we'll have a `-swift-version 5.1`. I also don't see why `init(ascii:)` makes sense to deprecate, since it can be useful for run-time values too. Finally,

> Some have proposed allowing integer _array_ types to be expressible by _multi-character_ ASCII strings such as `'abcd'`. We consider this to be out of scope of this proposal, as well as unsupported by precedent in C and related languages.

I agree that this is out of scope, but there is _some_ precedent for it: [multicharacter scalar literals](https://en.cppreference.com/w/cpp/language/character_literal#Notes) as an implementation-defined part of C and C++. I've definitely had use for "sequence of bytes that have a nice ASCII representation" in parsing code and I'd support such an addition in the future.

---

<div class="post-metadata">

**Author:** ![johnno1962](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/johnno1962/32/6805_2.png) [@johnno1962](https://forums.swift.org/u/johnno1962)\
**Post date:** [March 4, 2019, 5:16pm UTC](https://forums.swift.org/t/se-0243-codepoint-and-character-literals/21188/7 "2019-03-04T17:16:18Z")

</div>

> [@Nevin](#):
>
> I think `String` should _not_ be expressible by a single-quoted literal, only a double-quoted literal.

This isn’t ideal but difficult to avoid in a ABI stable world:

> [@Prepitch: Character integer literals](https://forums.swift.org/t/prepitch-character-integer-literals/10442/324):
>
> As ExpressibleByStringLiteral inherits from ExpressibleByExtendedGraphemeClusterLiteral which in turn inherits from ExpressibleByUnicodeScalarLiteral there won’t be an ABI stable way to stop `let a: String = ‘a’` from working. I don’t see it as a problem. This is the reason `’a’ + ‘b’ == “ab”` .

> [@Nevin](#):
>
> It is not clear to me why integers are restricted to being represented by ASCII characters only. Every Unicode scalar has a unique integer value, which is already available in Swift at runtime:

Greater flexibility would have been my preference but a long discussion about the subtleties of unicode normalisation persuaded the thread it was best to steer clear of being able to represent integers outside the ASCII range (The Option 2 vs. Option 4 debate). We can always relax this constraint later if a killer use-case turns up.

> [@Nevin](#):
>
> Therefore, perhaps we should make single-quoted characters also be valid _integer_ literals. Instead of trying to shoehorn integer types into accepting `UnicodeScalar` literals, we could simply make the compiler recognize single-quoted characters as another way to spell integer literals.

This was the first implementation proposed (Codepoint literals) but it became obvious the proper abstraction in the Swift string world for single quotes should be as _Character_ literals that can use the more flexible existing protocols for nearly the same result.

---

<div class="post-metadata">

**Author:** ![Michael\_Ilseman](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/michael_ilseman/32/44640_2.png) [@Michael\_Ilseman](https://forums.swift.org/u/Michael_Ilseman)\
**Post date:** [March 4, 2019, 5:34pm UTC](https://forums.swift.org/t/se-0243-codepoint-and-character-literals/21188/8 "2019-03-04T17:34:14Z")

</div>

> - What is your evaluation of the proposal?

+1 for the most part. As @jrose mentioned, why are we deprecating the init?

> [@jrose](#):
>
> I also don't see why `init(ascii:)` makes sense to deprecate, since it can be useful for run-time values too.

> - Is the problem being addressed significant enough to warrant a change to Swift?

Yes

> - Does this proposal fit well with the feel and direction of Swift?

Yes

> - If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

This is very similar

> - How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

In-depth study

---

<div class="post-metadata">

**Author:** ![Nevin](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/nevin/32/617_2.png) [@Nevin](https://forums.swift.org/u/Nevin)\
**Post date:** [March 4, 2019, 6:21pm UTC](https://forums.swift.org/t/se-0243-codepoint-and-character-literals/21188/9 "2019-03-04T18:21:56Z")

</div>

> [@johnno1962](#):
>
> > [@Nevin](#):
> >
> > Therefore, perhaps we should make single-quoted characters also be valid _integer_ literals. Instead of trying to shoehorn integer types into accepting `UnicodeScalar` literals, we could simply make the compiler recognize single-quoted characters as another way to spell integer literals.
> 
> This was the first implementation proposed (Codepoint literals) but it became obvious the proper abstraction in the Swift string world for single quotes should be as _Character_ literals that can use the more flexible existing protocols for nearly the same result.

I was trying to say _¿Porque no los dos?_

Use single-quoted literals for `ExpressibleByUnicodeScalarLiteral` with all the same conforming types as today.

Use single-quoted literals for `ExpressibleByExtendedGraphemeClusterLiteral` (sidenote: ugh, why was this not spelled `ExpressibleByCharacterLiteral`?) with all the same conforming types as today.

And also, use single-quoted literals for `ExpressibleByIntegerLiteral` with all the same conforming types as today.

> [@johnno1962](#):
>
> As ExpressibleByStringLiteral inherits from ExpressibleByExtendedGraphemeClusterLiteral which in turn inherits from ExpressibleByUnicodeScalarLiteral there won’t be an ABI stable way to stop `let a: String = ‘a’` from working. I don’t see it as a problem.

…just because the conformance is there, doesn’t mean we have to accept the syntax.

I have a vague recollection that some types conforming to `Collection` do not (or at least did not) allow direct subscripting, and this is/was intentional. It might have been some sort of `Range`, and the reasoning was that people don’t expect the subscript to be an identity operation. It still worked in generic contexts, it just wasn’t allowed to be used concretely.

I don’t know if that’s still the case, but I am fairly confident it was at some point.

So if we wanted to, I expect we could do something similar and make it an error to directly assign a single-quoted literal to a `String`.

> [@johnno1962](#):
>
> This is the reason `’a’ + ‘b’ == “ab”`.

Do we not have a `(Character, Character) -> String` overload of the `+` operator? Because that’s what I’d expect this to use.

---

<div class="post-metadata">

**Author:** ![Nevin](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/nevin/32/617_2.png) [@Nevin](https://forums.swift.org/u/Nevin)\
**Post date:** [March 4, 2019, 6:30pm UTC](https://forums.swift.org/t/se-0243-codepoint-and-character-literals/21188/10 "2019-03-04T18:30:23Z")

</div>

> [@johnno1962](#):
>
> Greater flexibility would have been my preference but a long discussion about the subtleties of unicode normalisation persuaded the thread it was best to steer clear of being able to represent integers outside the ASCII range (The Option 2 vs. Option 4 debate). We can always relax this constraint later if a killer use-case turns up.

This makes absolutely zero sense to me. A Unicode scalar has exactly one canonical integer value.

No normalization should be involved at all. If the source-file places a single Unicode scalar between two apostrophes, then that is a Unicode scalar literal.

It is a literal representation of a single Unicode scalar. And a single Unicode scalar has exactly one integer value, which can be accessed at runtime through its `value` property.

There is no ambiguity. If a Unicode scalar literal is used to express an integer value, then the only reasonable interpretation is to use the integer value of the Unicode scalar in the literal.

---

<div class="post-metadata">

**Author:** ![Alejandro](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/alejandro/32/46197_2.png) [@Alejandro](https://forums.swift.org/u/Alejandro)\
**Post date:** [March 4, 2019, 6:34pm UTC](https://forums.swift.org/t/se-0243-codepoint-and-character-literals/21188/11 "2019-03-04T18:34:00Z")

</div>

> [@Nevin](#):
>
> ¿Porque no los dos?

_Off topic and I apologize, but for those curious you can also say “porque no ambos?”_

---

<div class="post-metadata">

**Author:** ![taylorswift](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/taylorswift/32/43413_2.png) [@taylorswift](https://forums.swift.org/u/taylorswift)\
**Post date:** [March 4, 2019, 8:29pm UTC](https://forums.swift.org/t/se-0243-codepoint-and-character-literals/21188/12 "2019-03-04T20:29:14Z")

</div>

> [@Nevin](#):
>
> Review:
> 
> • I think `String` should _not_ be expressible by a single-quoted literal, only a double-quoted literal.

I used to agree with you, but it turns out taking `ExpressibleByStringLiteral` out of the text literal protocol hierarchy brings a lot of ABI issues with it, and in principle, `let s:String = 'a'` isn’t too different from `let f:Float = 1`. Complain all you want about the binary stability, but if you ask me it’s not worth fighting the ABI over this.

> [@Nevin](#):
>
> It is not clear to me why integers are restricted to being represented by ASCII characters only. Every Unicode scalar has a unique integer value, which is already available in Swift at runtime:

Early iterations of the proposal allowed exactly what you’re asking, but developers who use a lot of international text said there would be a lot of problems relating to unicode encoding once you get past U+0x7F. (literals that change value when you save the `.swift` file???) We think their concerns are valid, so we have the ASCII restriction.

> [@Michael\_Ilseman](#):
>
> +1 for the most part. As @jrose mentioned, why are we deprecating the init?

We don’t really have to. I don’t care too much about the `init(ascii:)` initializer and that part can be omitted from the proposal without affecting anything else.

> [@Nevin](#):
>
> Do we not have a `(Character, Character) -> String` overload of the `+` operator? Because that’s what I’d expect this to use.

We don’t. it’s okay, i could have sworn we had one too lol. One draft of the proposal said specifically to add this exact operator to `Character x Character` but once you have `'a' + 'a'` the next logical step is `'a' * 5`, which of course brings us to `'a' * 'a'` (???)

> [@Nevin](#):
>
> This makes absolutely zero sense to me. A Unicode scalar has exactly one canonical integer value.
> 
> No normalization should be involved at all. If the source-file places a single Unicode scalar between two apostrophes, then that is a Unicode scalar literal.
> 
> It is a literal representation of a single Unicode scalar. And a single Unicode scalar has exactly one integer value, which can be accessed at runtime through its `value` property.
> 
> There is no ambiguity. If a Unicode scalar literal is used to express an integer value, then the only reasonable interpretation is to use the integer value of the Unicode scalar in the literal.

[we’ve been over this](https://forums.swift.org/t/prepitch-character-integer-literals/10442/222)

---

<div class="post-metadata">

**Author:** ![Nevin](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/nevin/32/617_2.png) [@Nevin](https://forums.swift.org/u/Nevin)\
**Post date:** [March 4, 2019, 9:02pm UTC](https://forums.swift.org/t/se-0243-codepoint-and-character-literals/21188/13 "2019-03-04T21:02:19Z")

</div>

> [@taylorswift](#):
>
> [we’ve been over this](https://forums.swift.org/t/prepitch-character-integer-literals/10442/222)

That does not actually address the issue.

Saying “we’ve been over this” and linking to a post that simply dismisses the idea out of hand, is not conducive to a productive Swift Evolution discussion.

---

<div class="post-metadata">

**Author:** ![lorentey](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/lorentey/32/1299_2.png) [@lorentey](https://forums.swift.org/u/lorentey)\
**Post date:** [March 4, 2019, 9:02pm UTC](https://forums.swift.org/t/se-0243-codepoint-and-character-literals/21188/14 "2019-03-04T21:02:49Z")

</div>

> [@ben-cohen](#):
>
> - What is your evaluation of the proposal?

I like most parts, except for the proposed integer conformances. Integer literal initialization seems like a relatively niche feature that comes with an unreasonably large conceptual/pedagogical cost.

I can fully appreciate the convenience of being able to write code like this while I'm writing a parser for some binary file format that includes ASCII elements:

```swift
let magic: [UInt8] = ['G', 'I', 'F', '8', '9', 'a']

```

However, in the overwhelmingly vast majority of my time, I'm _not_ writing such a parser, and the notion that it's okay to consider some characters unambiguously _identical_ to their ASCII codes rubs me the wrong way.

By their nature, characters aren't integer values. There is nothing inherently "71ish" about the letter G; the idea that the digit 8 is the same thing as the number 56 is absurd.

We can _encode_ G and 8 to integers (or, rather, a series of bits) by selecting an encoding. There are many encodings to choose from, and not all use the same representations as ASCII; indeed, Swift has some support for running on IBM Z systems that prefer encodings from the EBCDIC family.

The Swift stdlib has so far been careful to always make the selection of an encoding explicit in Swift source code. This has been best practice in API design for multiple decades now, so I always assumed this was a deliberate choice -- any implicit encoding would certainly lead to hard-to-spot mistakes. This proposal is quite flagrantly breaking this practice. Limiting the feature to ASCII is a good compromise, but it does not fully eliminate the problem.

In view of this, I would prefer if the passage about eventually adding `ExpressibleByUnicodeScalarLiteral` conformance to `Int8`/.../`Int` was dropped from the proposal text. Instead, users should keep explicitly opting into the integer initialization feature, even if versioned conformances become available. The required one-liner conformance declaration honestly doesn't seem like an unreasonable burden for authors of parser packages.

The `UInt8(ascii:)` initializer should not be deprecated; rather, it should be added to all integer types. (The objections raised in the Alternatives Considered section seem quite weak to me.)

> [@ben-cohen](#):
>
> - Is the problem being addressed significant enough to warrant a change to Swift?

Yes, despite the objection above.

> [@ben-cohen](#):
>
> - Does this proposal fit well with the feel and direction of Swift?

Single-quoted `Unicode.Scalar` and `Character` literals are obviously desirable.

As detailed above, I consider integer initialization to be a bad idea in general. Limiting it to ASCII is a workable compromise; indefinitely leaving it opt-in would be even better.

> [@ben-cohen](#):
>
> - If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

I don't know any language that properly supports Unicode at the level Swift aims for. APIs that implicitly assume a string encoding are generally considered subpar in the libraries I worked with -- unfortunately, character initialization is often a legacy language feature that's has to be kept unchanged.

> [@ben-cohen](#):
>
> - How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

I was involved in late-stage pitch discussions, and thought long and hard about the issues.

---

<div class="post-metadata">

**Author:** ![taylorswift](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/taylorswift/32/43413_2.png) [@taylorswift](https://forums.swift.org/u/taylorswift)\
**Post date:** [March 4, 2019, 9:07pm UTC](https://forums.swift.org/t/se-0243-codepoint-and-character-literals/21188/15 "2019-03-04T21:07:07Z")

</div>

I think there is enough reason to give ASCII preferred treatment over all other encodings, just from the fact that so many major binary formats explicitly specify it. For example, [the png standard](http://www.libpng.org/pub/png/spec/1.2/PNG-Structure.html#Chunk-layout):

> 3.2. Chunk layout

> Each chunk consists of four parts:

> **Length**

> …

> **Chunk Type**

> A 4-byte chunk type code. For convenience in description and in examining PNG files, type codes are restricted to consist of uppercase and lowercase ASCII letters (A-Z and a-z, or 65-90 and 97-122 decimal). However, encoders and decoders must treat the codes as fixed binary values, not character strings. **For example, it would not be correct to represent the type code IDAT by the EBCDIC equivalents of those letters.** Additional naming conventions for chunk types are discussed in the next section.

Non-ASCII 7-bit encodings are so rare compared to Non-UTF8 \>7-bit encodings that i really don’t think it’s valid to use the same argument for both. We shouldn’t make the common case (ASCII) difficult to use just to accommodate a very _uncommon_ case (EBCDIC).

---

<div class="post-metadata">

**Author:** ![Nevin](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/nevin/32/617_2.png) [@Nevin](https://forums.swift.org/u/Nevin)\
**Post date:** [March 4, 2019, 9:07pm UTC](https://forums.swift.org/t/se-0243-codepoint-and-character-literals/21188/16 "2019-03-04T21:07:32Z")

</div>

> [@taylorswift](#):
>
> We don’t. it’s okay, i could have sworn we had one too lol. One draft of the proposal said specifically to add this exact operator to `Character x Character` but once you have `'a' + 'a'` the next logical step is `'a' * 5` , which of course brings us to `'a' * 'a'` (???)

Please don’t try to slippery-slope this.

We have a `+` operator that concatenates arrays, but nobody expects there to be a `*` operator that repeats an array n times. Some people might _want_ that, but we don’t have it and the slope is not slippery.

Furthermore, with the proposal in its current form, `'a' * 'a'` would be valid Swift (after a zero-effort user-supplied conformance, which is only required for ABI reasons), expressing the multiplication of 97 by itself as an integer. So if you think “`'a' * 'a'`” is objectionable, then it follows that the current proposal is as well.

---

<div class="post-metadata">

**Author:** ![Nevin](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/nevin/32/617_2.png) [@Nevin](https://forums.swift.org/u/Nevin)\
**Post date:** [March 4, 2019, 9:14pm UTC](https://forums.swift.org/t/se-0243-codepoint-and-character-literals/21188/17 "2019-03-04T21:14:58Z")

</div>

> [@taylorswift](#):
>
> Early iterations of the proposal allowed exactly what you’re asking, but developers who use a lot of international text said there would be a lot of problems relating to unicode encoding once you get past U+0x7F. (literals that change value when you save the `.swift` file???) We think their concerns are valid, so we have the ASCII restriction.

How is that any different from what we can write today:

```swift
let x = "θ" as Unicode.Scalar
let n = x.value

```

The only difference is that today the conversion from character literal to integer must happen at runtime, whereas it could be done at compile-time with exactly the same semantics.

I have seen zero examples of a problem with doing this at compile-time, that is not _also_ a problem with doing it at runtime as we can today.

---

<div class="post-metadata">

**Author:** ![taylorswift](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/taylorswift/32/43413_2.png) [@taylorswift](https://forums.swift.org/u/taylorswift)\
**Post date:** [March 4, 2019, 9:16pm UTC](https://forums.swift.org/t/se-0243-codepoint-and-character-literals/21188/18 "2019-03-04T21:16:22Z")

</div>

> [@Nevin](#):
>
> Furthermore, with the proposal in its current form, `'a' * 'a'` would be valid Swift (after a zero-effort user-supplied conformance, which is only required for ABI reasons), expressing the multiplication of 97 by itself as an integer. So if you think “ `'a' * 'a'` ” is objectionable, then it follows that the current proposal is as well.

your whole premise is that `'a'` shouldn’t be a `String`, but really there isn’t a strong argument why it shouldn’t be since and if we go with the ABI-friendly route, we get `'a' + 'a' = "aa"` for free. `'a' * 'a'` is unfortunate but we already decided for users, it’s fine since the type checker would almost certainly catch that mistake. For standard library authors, `'a' * 'a'` is a different question since if we are vending `+ (Character, Character) -> String`, we would also have to consider `* (Character, Int) -> String` along with it (python has it after all)

---

<div class="post-metadata">

**Author:** ![Nevin](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/nevin/32/617_2.png) [@Nevin](https://forums.swift.org/u/Nevin)\
**Post date:** [March 4, 2019, 9:25pm UTC](https://forums.swift.org/t/se-0243-codepoint-and-character-literals/21188/19 "2019-03-04T21:25:37Z")

</div>

> [@taylorswift](#):
>
> your whole premise is that `'a'` shouldn’t be a `String` , but really there isn’t a strong argument why it shouldn’t be since and if we go with the ABI-friendly route, we get `'a' + 'a' = "aa"` for free. `'a' * 'a'` is unfortunate but we already decided for users, it’s fine since the type checker would almost certainly catch that mistake.

The reason is clarity at the point of use. If we introduce single-quoted literals as this proposal suggests, then the difference between them and double-quoted literals should be meaningful:

`'a'` can be a `Character` or `Unicode.Scalar`, but not a `String` nor `StaticString`

`"a"` can be a `String` or `StaticString`, but not a `Character` nor `Unicode.Scalar`

That way the meaning of character and string literals in source code is much clearer.

> [@taylorswift](#):
>
> For standard library authors, `'a' * 'a'` is a different question since if we are vending `+ (Character, Character) -> String` , we would also have to consider `* (Character, Int) -> String` along with it (python has it after all)

Seriously, please stop with the slippery-sloping. We are under no obligation to consider any such thing, and even if we did consider it we have no obligation to adopt it.

---

<div class="post-metadata">

**Author:** ![taylorswift](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/taylorswift/32/43413_2.png) [@taylorswift](https://forums.swift.org/u/taylorswift)\
**Post date:** [March 4, 2019, 9:38pm UTC](https://forums.swift.org/t/se-0243-codepoint-and-character-literals/21188/21 "2019-03-04T21:38:13Z")

</div>

off topic but @johnno1962 why does `let s:String = 'a'` work again? `String`’s ExpressibleByExtendedGraphemeClusterLiteral conformance takes a `String` argument

```swift
String.init(extendedGraphemeClusterLiteral: "a" as Character)
error: repl.swift:3:49: error: cannot convert value of type 'Character' to expected argument type 'String'

```

[Next page](https://forums.swift.org/t/se-0243-codepoint-and-character-literals/21188.md?page=2)