-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> 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 > > _______________________________________________ > 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