This sounds awesome to me, except I'd take it a bit further and bring this idea
to its logical conclusion: creating concrete type subtypes.
Take, for example the CGFloat, which is a struct, that's essentially a subtype
of Double.
Seems like what you actually want is to create a subtype of String, while
leaving String completely intact.
You could have defined a new type HeaderKey, have a single String member in it
and define call forwarding functions that you need, which would solve your use
case perfectly.
The only downside is the horrible amount of boilerplate you'd have to write,
which is where some syntactic sugar could be introduced.
indirect struct HeaderKey {
var value: String // Indirect structs must have exactly one stored
variable named `value`.
}
extension HeaderKey: CustomStringInitializable {
/// Implementing conformance is optional if `self.value` conforms to it.
}
> On Jun 9, 2017, at 6:37 PM, Remy Demarest 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
