> 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 Robert Bennett via swift-evolution > <swift-evolution@swift.org <mailto: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 be subtyped because their size must > be known at compile time. I don’t know the implementation details of where > functions and computed properties live, but something tells me they belong to > the type and not the object (although I’ve never really made the effort to > sit down and fully understand Swift’s type model), in which case adding them > to a struct’s definition would not change the size of the object on the > stack. Thus it should be possible to make custom substructs of String that > add additional functionality but no new stored properties. Thoughts? > > Value subtyping is a large subject and, IIUC, newtype would be a subset of > that topic. Unlikely to be in scope for Swift 5, though, but that’s up to the > core team.
I see newtype as being more related to forwarding than subtyping. Usually you want to hide significant parts of the interface to the wrapped type. > > > On Jun 9, 2017, at 12:12 PM, Jacob Williams via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > >>> On Jun 9, 2017, at 9:53 AM, Charlie Monroe <char...@charliemonroe.net >>> <mailto:char...@charliemonroe.net>> 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 { >>> ... >>> } >> >> I really don’t see how this disallows code sharing between the two systems? >> Could you explain further? Based on my understanding of the pitch, this is >> valid code still. (Although I do like the suggestion of a new keyword rather >> than just limiting type alias). >> >> Even if your example was invalid, you could also just do something like this: >> >> #if os(iOS) >> typealias XUView = UIView >> extension XUView { >> //extension code here >> } >> #if os(macOS) >> typealias XUView = UIView >> extension XUView { >> // extension code here >> } >> #endif >> >> While not as pretty, still just as effective if you have to deal with >> different types based on the system being compiled for and you could easily >> still make the type alias extensions for each type work the same. >> >>> On Jun 9, 2017, at 9:53 AM, Charlie Monroe <char...@charliemonroe.net >>> <mailto:char...@charliemonroe.net>> 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 { >>> ... >>> } >>> >>> or with any similar compatibility typealiases. >>> >>>> On Jun 9, 2017, at 5:38 PM, Jacob Williams via swift-evolution >>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>>> >>>> +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 aliases (and >>>> only the type alias), or if it were possible to inherit from structs so >>>> that we could create a custom string type like so: >>>> >>>> struct HeaderKey: String { >>>> static var lastModified: String { return “Last-Modified” } >>>> static var host: String { return “Host” } >>>> } >>>> >>>> I realize that struct inheritance is far less likely, since that defeats >>>> one of the main pieces of what makes a struct a struct. So I’m all for >>>> this proposal of allowing type aliases to be extended as though they were >>>> their own struct/class. >>>> >>>> Unfortunately, I’m not sure how feasible this kind of functionality would >>>> actually be, but if it’s possible then I’m in favor of implementing it. >>>> >>>>> On Jun 8, 2017, at 10:14 PM, Yvo van Beek via swift-evolution >>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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. >>>>> >>>>> 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 that, but as an example). I could write something like this: >>>>> >>>>> typealias HeaderKey = String >>>>> >>>>> var headers = [HeaderKey: String]() >>>>> headers["Host"] = "domain.com <http://domain.com/>" >>>>> >>>>> Now I can define a couple of default headers like this: >>>>> >>>>> extension HeaderKey { >>>>> static var lastModified: String { return "Last-Modified" } >>>>> static var host: String { return "Host" } >>>>> } >>>>> >>>>> After that I can do this: >>>>> >>>>> var headers = [HeaderKey: String]() >>>>> headers[.host] = "domain.com <http://domain.com/>" >>>>> headers[.lastModified] = "some date" >>>>> headers["X-MyHeader"] = "This still works too" >>>>> >>>>> But unfortunately the extension is also applied to normal strings: >>>>> >>>>> var normalString: String = .host >>>>> >>>>> Perhaps it would be better if the extension would only apply to the parts >>>>> of my code where I use the HeaderKey typealias and not to all Strings. >>>>> This could be a great tool to specialize classes by creating a typealias >>>>> and adding functionality to it. Another example I can think of is >>>>> typealiases for dictionaries or arrays with added business logic through >>>>> extensions (especially since you can't inherit from structs). >>>>> >>>>> If you want to create an extension that adds functionality to all Strings >>>>> you could have created an extension for String instead of HeaderKey. >>>>> >>>>> Please let me know what you think. I'm not sure how complex this change >>>>> would be. >>>>> I could write a proposal if you're interested. >>>>> >>>>> Kind regards, >>>>> Yvo >>>>> _______________________________________________ >>>>> swift-evolution mailing list >>>>> swift-evolution@swift.org <mailto: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 <mailto: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 <mailto: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 <mailto: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
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
