-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
> <[email protected]> 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
>> <[email protected] <mailto:[email protected]>> 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
>> [email protected] <mailto:[email protected]>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
