# Newtype for Swift

**URL:** <https://forums.swift.org/t/newtype-for-swift/35859>\
**Category:** Discussion\
**Created:** [April 26, 2020, 5:22am UTC](https://forums.swift.org/t/newtype-for-swift/35859 "2020-04-26T05:22:57Z")\
**Posts on this page:** 1\
**Showing post:** 4

<div class="post-metadata">

**Author:** ![tomlokhorst](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/tomlokhorst/32/687_2.png) [@tomlokhorst](https://forums.swift.org/u/tomlokhorst)\
**Post date:** [April 26, 2020, 8:27am UTC](https://forums.swift.org/t/newtype-for-swift/35859/4 "2020-04-26T08:27:49Z")

</div>

> [@Jon\_Shier](#):
>
> `newtype` s inherit all of the functionality and conformances of the original type, but are considered separate types.

As the author of the [original pitch](https://forums.swift.org/t/newtype-without-automatic-protocol-forwarding/16110) I think I should reiterate why we didn’t want to automatically inherit all conformances of the original type.

One of our motivating examples was Identifiers:

```swift
struct Person {
  newtype Identifier = String

  let id: Identifier
  let name: String
}

```

Here, we don’t want Identifier to inherit almost any of the many features String has. We don’t want to concat two Identifiers, we don’t want to create a substring from an Identifier. None of those features make any sense.  
In fact, the _only_ thing we want from Identifier is Equatable, Hashable en perhaps CustomStringConvertable (but only for debugging).

So if `newtype` _automatically_ inherits all the behaviours of the original type, it would make it less useful for me, because now I can no longer use it for Identifiers.

Additionally, it would be really nice to _optionally_ request to inherit (forward) existing behaviour. In cases where it is needed, like in a lot of Int/Float examples.

---

_[View the full topic](https://forums.swift.org/t/newtype-for-swift/35859)._