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 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. On Jun 9, 2017, at 12:12 PM, Jacob Williams via swift-evolution < > swift-evolution@swift.org> wrote: > > On Jun 9, 2017, at 9:53 AM, Charlie Monroe <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> > 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> 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> 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@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 > > _______________________________________________ > 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