Re: [swift-evolution] Pitch: Limit typealias extensions to the typealias

on Fri Jun 09 2017, Matthew Johnson wrote: >> On Jun 9, 2017, at 12:09 PM, Xiaodi Wu via swift-evolution >> wrote: >> >> On Fri, Jun 9, 2017 at 12:44 Robert Bennett via swift-evolution >> >>

Re: [swift-evolution] Pitch: Limit typealias extensions to the typealias

> On Jun 9, 2017, at 16:38, Daryle Walker via swift-evolution > wrote: > > >> On Jun 9, 2017, at 12:14 AM, Yvo van Beek via swift-evolution >> wrote: >> >> Typealiases can greatly reduce the complexity of code. But I think one >>

Re: [swift-evolution] Pitch: Limit typealias extensions to the typealias

> On Jun 9, 2017, at 12:14 AM, Yvo van Beek via swift-evolution > wrote: > > Typealiases can greatly reduce the complexity of code. But I think one change > in how the compiler handles them could make them even more powerful. [SNIP] > Perhaps it would be better if

Re: [swift-evolution] Pitch: Limit typealias extensions to the typealias

@Doug: It might indeed be confusing to use "typealias" for this. Looking at the HeaderKey example, alternatives could be: 1) struct inheritance (HeaderKey would inherit from String), value subtyping? 2) the ability to specify implicit conversion between types, C# has the implicit keyword

Re: [swift-evolution] Pitch: Limit typealias extensions to the typealias

> On 9. Jun 2017, at 21:47, Matthew Johnson via swift-evolution > wrote: > > >> On Jun 9, 2017, at 2:39 PM, Xiaodi Wu > > wrote: >> >> Interesting. So you’d want `newtype Foo = String` to start off with no >>

Re: [swift-evolution] Pitch: Limit typealias extensions to the typealias

+1 to this. My ideal imagining of this behavior is to: 1) Define a protocol containing the precise operations you want to support via forwarding. 2) Internally/fileprivately extend the original type to conform to this protocol. 3) In your new type, tell it to forward protocol members for a

Re: [swift-evolution] Pitch: Limit typealias extensions to the typealias

> On Jun 9, 2017, at 2:53 PM, Tony Allevato wrote: > > +1 to this. My ideal imagining of this behavior is to: > > 1) Define a protocol containing the precise operations you want to support > via forwarding. > 2) Internally/fileprivately extend the original type to

Re: [swift-evolution] Pitch: Limit typealias extensions to the typealias

On Fri, Jun 9, 2017 at 15:47 Matthew Johnson wrote: > On Jun 9, 2017, at 2:39 PM, Xiaodi Wu wrote: > > Interesting. So you’d want `newtype Foo = String` to start off with no > members on Foo? > > > Yeah. Previous discussions of newtype have usually

Re: [swift-evolution] Pitch: Limit typealias extensions to the typealias

> On Jun 9, 2017, at 3:16 PM, Tony Allevato wrote: > > Makes sense. I guess from an implementation point of view, the compiler only > needs to be able to see the signatures of the members to synthesize the calls > to them. My thinking was that conforming the original

Re: [swift-evolution] Pitch: Limit typealias extensions to the typealias

Makes sense. I guess from an implementation point of view, the compiler only needs to be able to see the signatures of the members to synthesize the calls to them. My thinking was that conforming the original type would remove the need for the compiler to verify separately that the members exist

Re: [swift-evolution] Pitch: Limit typealias extensions to the typealias

> On Jun 9, 2017, at 2:39 PM, Xiaodi Wu wrote: > > Interesting. So you’d want `newtype Foo = String` to start off with no > members on Foo? Yeah. Previous discussions of newtype have usually led to discussion of ways to forward using a protocol-oriented approach.

Re: [swift-evolution] Pitch: Limit typealias extensions to the typealias

Interesting. So you’d want `newtype Foo = String` to start off with no members on Foo? On Fri, Jun 9, 2017 at 15:18 Matthew Johnson wrote: > On Jun 9, 2017, at 12:09 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > On Fri, Jun 9, 2017 at 12:44

Re: [swift-evolution] Pitch: Limit typealias extensions to the typealias

> On Jun 9, 2017, at 12:09 PM, Xiaodi Wu via swift-evolution > wrote: > > On Fri, Jun 9, 2017 at 12:44 Robert Bennett via swift-evolution > > wrote: > Somewhat related to this, shouldn’t it be possible to

Re: [swift-evolution] Pitch: Limit typealias extensions to the typealias

On Fri, Jun 9, 2017 at 12:44 Robert Bennett via swift-evolution < swift-evolution@swift.org> wrote: > Somewhat related to this, shouldn’t it be possible to sub-struct a struct > as long as you only add functions and computed properties (i.e., no stored > properties)? Traditionally structs cannot

Re: [swift-evolution] Pitch: Limit typealias extensions to the typealias

> On Jun 9, 2017, at 6:12 PM, Jacob Williams wrote: > >> On Jun 9, 2017, at 9:53 AM, Charlie Monroe > > wrote: >> >> -1 - this would disallow e.g. to share UI code between iOS and macOS: >> >> #if os(iOS) >>

Re: [swift-evolution] Pitch: Limit typealias extensions to the typealias

Somewhat related to this, shouldn’t it be possible to sub-struct a struct as long as you only add functions and computed properties (i.e., no stored properties)? Traditionally structs cannot be subtyped because their size must be known at compile time. I don’t know the implementation details of

Re: [swift-evolution] Pitch: Limit typealias extensions to the typealias

> On Jun 9, 2017, at 9:53 AM, Charlie Monroe wrote: > > -1 - this would disallow e.g. to share UI code between iOS and macOS: > > #if os(iOS) > typealias XUView = UIView > #else > typealias XUView = NSView > #endif > > extension XUView { > ... > }

Re: [swift-evolution] Pitch: Limit typealias extensions to the typealias

-1 - this would disallow e.g. to share UI code between iOS and macOS: #if os(iOS) typealias XUView = UIView #else typealias XUView = NSView #endif extension XUView { ... } or with any similar compatibility typealiases. > On Jun 9, 2017, at 5:38 PM, Jacob Williams via

Re: [swift-evolution] Pitch: Limit typealias extensions to the typealias

I feel like this might be better served by something like newtype which I know I've seen floating around on this list before. The idea is that something like: newtype HeaderKey = String would serve roughly as syntactic sugar for something like struct HeaderKey { let value: String init(_

Re: [swift-evolution] Pitch: Limit typealias extensions to the typealias

+1 from me. There have been times I’ve wanted to subclass an object (such as String) but since it is a non-class, non-protocol type you can only extend Strings existing functionality which adds that same functionality to Strings everywhere. It would be nice if we could either extend type

[swift-evolution] Pitch: Limit typealias extensions to the typealias

Typealiases can greatly reduce the complexity of code. But I think one change in how the compiler handles them could make them even more powerful. Let's say I'm creating a web server framework and I've created a simple dictionary to store HTTP headers (I know that headers are more complex than