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

[Xiaodi Wu]

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 <matthew at anandabits.com> wrote:

> On Jun 9, 2017, at 12:09 PM, Xiaodi Wu via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> On Fri, Jun 9, 2017 at 12:44 Robert Bennett via swift-evolution <
> swift-evolution at 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 at swift.org> wrote:
>>
>> On Jun 9, 2017, at 9:53 AM, Charlie Monroe <charlie at 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 <charlie at 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 at 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 at 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"
>>
>> 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"
>>   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 at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170609/45d6dcf5/attachment.html>