# .hasSuffix

**URL:** <https://forums.swift.org/t/hassuffix/19699>\
**Category:** Using Swift\
**Created:** [January 22, 2019, 11:55am UTC](https://forums.swift.org/t/hassuffix/19699 "2019-01-22T11:55:34Z")\
**Posts on this page:** 1\
**Showing post:** 14

<div class="post-metadata">

**Author:** ![SDGGiesbrecht](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/sdggiesbrecht/32/4768_2.png) [@SDGGiesbrecht](https://forums.swift.org/u/SDGGiesbrecht)\
**Post date:** [January 23, 2019, 5:34pm UTC](https://forums.swift.org/t/hassuffix/19699/14 "2019-01-23T17:34:52Z")

</div>

(@modyX, ignore us. I’m answering others here and it will get complicated fast.)

The fix is great.

> [@QuinceyMorris](#):
>
> The Unicode normalization form is an implementation detail which the compiler (AFAIK) is not obligated to maintain one way or the other.

`String` is obligated to preserve the same scalar sequence. If it did not, `String.UnicodeScalarView`, `String.UTF8View`, etc would all break.

Even if the entire API and implementation were overhauled in the future, there will always be access to preserved scalars for the text processing which needs it.

> [@String’s ABI and UTF-8](https://forums.swift.org/t/string-s-abi-and-utf-8/17676/14):
>
> No, this will not be a 100%-case guarantee. ABI stability (and lazily bridged NSString on Darwin platforms) dictates that String will always need to handle non-NFC-normalized contents. String has [a performance flag](https://github.com/apple/swift/blob/e272ece309ce710c8d778ce691ddc17a8ec0e653/stdlib/public/core/StringObject.swift#L851) that can be set when the contents are known to be NFC. If the bit is not set, the standard library has to treat the contents as non-NFC. ABI stability means that all future versions of the standard library have to handle strings with and without that bit set. The performance goal is…

---

_[View the full topic](https://forums.swift.org/t/hassuffix/19699)._