# Proposal: newtype feature for creating brand new types from existing types **URL:** \ **Category:** Discussion\ **Created:** [December 11, 2015, 8:09pm UTC](https://forums.swift.org/t/proposal-newtype-feature-for-creating-brand-new-types-from-existing-types/454 "2015-12-11T20:09:29Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![Tuuranton](https://avatars.discourse-cdn.com/v4/letter/t/76d3ee/32.png) [@Tuuranton](https://forums.swift.org/u/Tuuranton)\ **Post date:** [December 11, 2015, 8:09pm UTC](https://forums.swift.org/t/proposal-newtype-feature-for-creating-brand-new-types-from-existing-types/454/1 "2015-12-11T20:09:29Z")
//Existing typealias feature.//Foo acts exactly the same way as Double. It's the same thing.//Double can be used instead of Foo anywhere.typealias Foo = Double //Proposed newtype feature.//Bar acts exactly the same way as Double and is the same//thing behind the scenes (until we extend it; see below).//Trying to use Double instead of Bar will result in a compile-time error.newtype Bar = Double Of course, after creating Bar - a "copy" of the type Double, so to speak - I can extend Bar independenly of Double as one would expect. This would be highly useful. Your thoughts? ---
**Author:** ![gwendal.roue](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/gwendal.roue/32/13992_2.png) [@gwendal.roue](https://forums.swift.org/u/gwendal.roue)\ **Post date:** [December 11, 2015, 8:30pm UTC](https://forums.swift.org/t/proposal-newtype-feature-for-creating-brand-new-types-from-existing-types/454/2 "2015-12-11T20:30:46Z")
Considering the number of times I’ve read about this topic in other languages, I must agree :-) Yet there are two difficulties: First, what does Bar get from Double ? When you say "after creating Bar, I can extend Bar independenly of Double", the problem lies in the meaning of "after". In a language like Ruby, there is an "after", but there is no such clear thing in Swift: modules/packages are compiled as a whole, and module A can extend a type defined the the module B. More, let’s see what happens below: 1 let d: Double = 1.0 2 let b: Bar = d // Compiler error, I presume. 3 let b: Bar = Bar(d) // Mandatory so that Bar can be put to any use 4 let b: Bar = 1.0 That point 4 is tricky. If it is not an error, then 2. should succeed as well, don’t you think? If it is an error, then one may want to add FloatLiteralConvertible to Bar. Oops, Double already implements it. Hm. I’m afraid I haven’t found the solution :-) Gwendal Roué > **···** > > > Le 11 déc. 2015 à 21:09, Tuur Anton via swift-evolution \ a écrit : > > > > //Existing typealias feature. > > //Foo acts exactly the same way as Double. It's the same thing. > > //Double can be used instead of Foo anywhere. > > typealias Foo = Double > > > > //Proposed newtype feature. > > //Bar acts exactly the same way as Double and is the same > > //thing behind the scenes (until we extend it; see below). > > //Trying to use Double instead of Bar will result in a compile-time error. > > newtype Bar = Double > > > > Of course, after creating Bar - a "copy" of the type Double, so to speak - I can extend Bar independenly of Double as one would expect. > > > > This would be highly useful. > > > > Your thoughts? > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![Alejandro\_Martinez](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/alejandro_martinez/32/821_2.png) [@Alejandro\_Martinez](https://forums.swift.org/u/Alejandro_Martinez)\ **Post date:** [December 11, 2015, 8:34pm UTC](https://forums.swift.org/t/proposal-newtype-feature-for-creating-brand-new-types-from-existing-types/454/3 "2015-12-11T20:34:26Z")
A similar thing has been already mentioned in the list. I can remember the topic "[swift-evolution] protocol based invocation forwarding" which could resolve in a similar feature. As I said in there I would be really interested to see this in the language as will allow us to be more type safe with types that are commonly described as strings or numbers, but that are more than that. Cheers, > **···** > > > El 11 dic 2015, a las 20:30, Gwendal Roué via swift-evolution \ escribió: > > > > Considering the number of times I’ve read about this topic in other languages, I must agree :-) > > > > Yet there are two difficulties: > > > > First, what does Bar get from Double ? > > > > When you say "after creating Bar, I can extend Bar independenly of Double", the problem lies in the meaning of "after". In a language like Ruby, there is an "after", but there is no such clear thing in Swift: modules/packages are compiled as a whole, and module A can extend a type defined the the module B. > > > > More, let’s see what happens below: > > > > 1 let d: Double = 1.0 > > 2 let b: Bar = d // Compiler error, I presume. > > 3 let b: Bar = Bar(d) // Mandatory so that Bar can be put to any use > > 4 let b: Bar = 1.0 > > > > That point 4 is tricky. > > > > If it is not an error, then 2. should succeed as well, don’t you think? > > If it is an error, then one may want to add FloatLiteralConvertible to Bar. Oops, Double already implements it. > > > > Hm. I’m afraid I haven’t found the solution :-) > > > > Gwendal Roué > > > > > Le 11 déc. 2015 à 21:09, Tuur Anton via swift-evolution \\> a écrit : > > > > > > //Existing typealias feature. > > > //Foo acts exactly the same way as Double. It's the same thing. > > > //Double can be used instead of Foo anywhere. > > > typealias Foo = Double > > > > > > //Proposed newtype feature. > > > //Bar acts exactly the same way as Double and is the same > > > //thing behind the scenes (until we extend it; see below). > > > //Trying to use Double instead of Bar will result in a compile-time error. > > > newtype Bar = Double > > > > > > Of course, after creating Bar - a "copy" of the type Double, so to speak - I can extend Bar independenly of Double as one would expect. > > > > > > This would be highly useful. > > > > > > Your thoughts? > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > swift-evolution mailing list > > > swift-evolution@swift.org \ > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![Nicky\_Gerritsen](https://avatars.discourse-cdn.com/v4/letter/n/b5a626/32.png) [@Nicky\_Gerritsen](https://forums.swift.org/u/Nicky_Gerritsen)\ **Post date:** [December 11, 2015, 8:34pm UTC](https://forums.swift.org/t/proposal-newtype-feature-for-creating-brand-new-types-from-existing-types/454/4 "2015-12-11T20:34:16Z")
> Considering the number of times I’ve read about this topic in other languages, I must agree :-) > > Yet there are two difficulties: > > First, what does Bar get from Double ? > > When you say "after creating Bar, I can extend Bar independenly of Double", the problem lies in the meaning of "after". In a language like Ruby, there is an "after", but there is no such clear thing in Swift: modules/packages are compiled as a whole, and module A can extend a type defined the the module B. > > More, let’s see what happens below: > > 1 let d: Double = 1.0 > 2 let b: Bar = d // Compiler error, I presume. > 3 let b: Bar = Bar(d) // Mandatory so that Bar can be put to any use > 4 let b: Bar = 1.0 > > That point 4 is tricky. > > If it is not an error, then 2. should succeed as well, don’t you think? > If it is an error, then one may want to add FloatLiteralConvertible to Bar. Oops, Double already implements it. But that is not true. Take this example: let x: Int = 3 // Type added for clarity let y: Double = x // error let z: Double = 3 // ok This is exactly why it is Float\_Literal\_Convertible, it can only convert literals ;). Anyway, about the general thing: isn’t this just inheritance, but then for struct types? i.e. struct Bar : Double {} — Nicky > **···** > > > On 11 dec. 2015, at 21:30, Gwendal Roué via swift-evolution \ wrote: > > > > Hm. I’m afraid I haven’t found the solution :-) > > > > Gwendal Roué > > > > > Le 11 déc. 2015 à 21:09, Tuur Anton via swift-evolution \\> a écrit : > > > > > > //Existing typealias feature. > > > //Foo acts exactly the same way as Double. It's the same thing. > > > //Double can be used instead of Foo anywhere. > > > typealias Foo = Double > > > > > > //Proposed newtype feature. > > > //Bar acts exactly the same way as Double and is the same > > > //thing behind the scenes (until we extend it; see below). > > > //Trying to use Double instead of Bar will result in a compile-time error. > > > newtype Bar = Double > > > > > > Of course, after creating Bar - a "copy" of the type Double, so to speak - I can extend Bar independenly of Double as one would expect. > > > > > > This would be highly useful. > > > > > > Your thoughts? > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > swift-evolution mailing list > > > swift-evolution@swift.org \ > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![Russ\_Bishop1](https://avatars.discourse-cdn.com/v4/letter/r/ccd318/32.png) [@Russ\_Bishop1](https://forums.swift.org/u/Russ_Bishop1)\ **Post date:** [December 15, 2015, 7:15am UTC](https://forums.swift.org/t/proposal-newtype-feature-for-creating-brand-new-types-from-existing-types/454/5 "2015-12-15T07:15:42Z")
My assumption is that the proposed newtype simply adopts the storage and any available functions, operators, and extensions available on the original type. Extensions on Double are available to Double and Bar. Extensions explicitly on Bar are only available on Bar. That said, I'm not sure this is worth the complexity when you can just wrap a Double inside your own struct Bar {} and get most of the benefits. Russ Bishop russbishop.net > **···** > > On Fri, Dec 11, 2015 at 12:30 PM, Gwendal Roué \ wrote: > > > Considering the number of times I’ve read about this topic in other > > languages, I must agree :-) > > > > Yet there are two difficulties: > > > > First, what does Bar get from Double ? > > > > When you say "after creating Bar, I can extend Bar independenly of > > Double", the problem lies in the meaning of "after". In a language like > > Ruby, there is an "after", but there is no such clear thing in Swift: > > modules/packages are compiled as a whole, and module A can extend a type > > defined the the module B. > > > > More, let’s see what happens below: > > > > 1 let d: Double = 1.0 > > 2 let b: Bar = d // Compiler error, I presume. > > 3 let b: Bar = Bar(d) // Mandatory so that Bar can be put to any use > > 4 let b: Bar = 1.0 > > > > That point 4 is tricky. > > > > If it is not an error, then 2. should succeed as well, don’t you think? > > If it is an error, then one may want to add FloatLiteralConvertible to > > Bar. Oops, Double already implements it. > > > > Hm. I’m afraid I haven’t found the solution :-) > > > > Gwendal Roué > > > > Le 11 déc. 2015 à 21:09, Tuur Anton via swift-evolution \< \> swift-evolution@swift.org\> a écrit : > > > > //Existing typealias feature. > > //Foo acts exactly the same way as Double. It's the same thing. > > //Double can be used instead of Foo anywhere. > > typealias Foo = Double > > > > //Proposed newtype feature. > > //Bar acts exactly the same way as Double and is the same > > //thing behind the scenes (until we extend it; see below). > > //Trying to use Double instead of Bar will result in a compile-time error. > > newtype Bar = Double > > > > Of course, after creating Bar - a "copy" of the type Double, so to speak - > > I can extend Bar independenly of Double as one would expect. > > > > This would be highly useful. > > > > Your thoughts? > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![Alejandro\_Martinez](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/alejandro_martinez/32/821_2.png) [@Alejandro\_Martinez](https://forums.swift.org/u/Alejandro_Martinez)\ **Post date:** [December 11, 2015, 8:38pm UTC](https://forums.swift.org/t/proposal-newtype-feature-for-creating-brand-new-types-from-existing-types/454/6 "2015-12-11T20:38:36Z")
> Anyway, about the general thing: isn’t this just inheritance, but then for struct types? > i.e. > > struct Bar : Double {} Not exactly as inheritance will let you use Bar in any place where do you expect Double. Presumably newtype does not. > **···** > > > El 11 dic 2015, a las 20:34, Nicky Gerritsen via swift-evolution \ escribió: > > > > > On 11 dec. 2015, at 21:30, Gwendal Roué via swift-evolution \\> wrote: > > > > > > Considering the number of times I’ve read about this topic in other languages, I must agree :-) > > > > > > Yet there are two difficulties: > > > > > > First, what does Bar get from Double ? > > > > > > When you say "after creating Bar, I can extend Bar independenly of Double", the problem lies in the meaning of "after". In a language like Ruby, there is an "after", but there is no such clear thing in Swift: modules/packages are compiled as a whole, and module A can extend a type defined the the module B. > > > > > > More, let’s see what happens below: > > > > > > 1 let d: Double = 1.0 > > > 2 let b: Bar = d // Compiler error, I presume. > > > 3 let b: Bar = Bar(d) // Mandatory so that Bar can be put to any use > > > 4 let b: Bar = 1.0 > > > > > > That point 4 is tricky. > > > > > > If it is not an error, then 2. should succeed as well, don’t you think? > > > If it is an error, then one may want to add FloatLiteralConvertible to Bar. Oops, Double already implements it. > > > > But that is not true. Take this example: > > > > let x: Int = 3 // Type added for clarity > > let y: Double = x // error > > let z: Double = 3 // ok > > > > This is exactly why it is Float\_Literal\_Convertible, it can only convert literals ;). > > > > Anyway, about the general thing: isn’t this just inheritance, but then for struct types? > > i.e. > > > > struct Bar : Double {} > > > > — Nicky > > > > > Hm. I’m afraid I haven’t found the solution :-) > > > > > > Gwendal Roué > > > > > > > Le 11 déc. 2015 à 21:09, Tuur Anton via swift-evolution \\> a écrit : > > > > > > > > //Existing typealias feature. > > > > //Foo acts exactly the same way as Double. It's the same thing. > > > > //Double can be used instead of Foo anywhere. > > > > typealias Foo = Double > > > > > > > > //Proposed newtype feature. > > > > //Bar acts exactly the same way as Double and is the same > > > > //thing behind the scenes (until we extend it; see below). > > > > //Trying to use Double instead of Bar will result in a compile-time error. > > > > newtype Bar = Double > > > > > > > > Of course, after creating Bar - a "copy" of the type Double, so to speak - I can extend Bar independenly of Double as one would expect. > > > > > > > > This would be highly useful. > > > > > > > > Your thoughts? > > > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > > swift-evolution mailing list > > > > swift-evolution@swift.org \ > > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > swift-evolution mailing list > > > swift-evolution@swift.org \ > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org \ > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution)