# 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:** 9

<div class="post-metadata">

**Author:** ![anandabits](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/anandabits/32/355_2.png) [@anandabits](https://forums.swift.org/u/anandabits)\
**Post date:** [April 26, 2020, 2:15pm UTC](https://forums.swift.org/t/newtype-for-swift/35859/9 "2020-04-26T14:15:38Z")

</div>

> [@Jon\_Shier](#):
>
> Before diving into specific syntax or implementation details I think it would be good to gather ideas about what people want out of such a feature and what they feel is most important.

I agree. Most of the discussion so far is focused on mechanics and not the problem to be solved.

Single property structs are trivial to write. Properties can easily be forwarded using `@dynamicMemberLookup`. Protocol conformances can easily be forwarded [using a protocol](https://gist.github.com/tomlokhorst/cb634deeea5793206c033439f814c4b9).

There are some things that are not possible today such as:

- forwarding methods that are not part of a protocol
- encapsulating the wrapped value while still forwarding protocols
- forwarding some protocols but not others (this is possibly, but only with a parallel set of forwarding protocols)

I think we need to be really clear about the use cases that are not well supported by the language today and would therefore make good motivation for a new language feature.

I dug up an old thread I had written about [protocol-based forwarding](https://forums.swift.org/t/proposal-draft-automatic-protocol-forwarding/817). I was working on a second draft of that pitch when the Swift 3 proposal pause happened and never picked it up again. Some of the details should look different than the ones in that thread, but I still think a more general protocol-based forwarding feature is the right direction. It would be useful in many cases where `newtype` alone would not. `newtype` would still be possible to add as additional sugar.

> [@tomlokhorst](#):
>
> 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).

This is somewhat representative of the kind of example that might make good motivation. However, I personally think there is benefit in handing identifiers using a single generic `ID` type parameterized by a “scope” rather than a bunch distinct newtypes.

---

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