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

[Yvo van Beek]

@Doug:

It might indeed be confusing to use "typealias" for this.

Looking at the HeaderKey example, alternatives could be:
1) struct inheritance (HeaderKey would inherit from String), value
subtyping?
2) the ability to specify implicit conversion between types, C# has
the implicit
keyword
<https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/implicit>
for this

@Will:

Your solution of creating a HeaderKey struct resolves most issues, but has
a few downsides:
1) the HeaderKey struct would contain quite some boilerplate code that
mimics String (Equality, CustomStringConvertible etc.)
2) the ExpressibleByStringLiteral enables the use of static strings, but a
dynamic string would need to be wrapped: HeaderKey(dynamicHeader) leading
to clunky code
3) the headers dictionary would become more difficult to process, the key
would no longer be an actual String, resulting in more code that distracts
from the actual code

Thanks everyone for chiming in on this.


On Fri, Jun 9, 2017 at 11:41 AM, Will Field-Thompson <will.a.ft at gmail.com>
wrote:

> I feel like this might be better served by something like newtype which I
> know I've seen floating around on this list before. The idea is that
> something like:
>
> newtype HeaderKey = String
>
> would serve roughly as syntactic sugar for something like
>
> struct HeaderKey {
>    let value: String
>    init(_ value: String) { self.value = value }
>    /* Possibly insert methods from String here, possibly do something
> else, whatever */
> }
>
> I've always thought this might be interesting, but there's a few reasons I
> suggest it in place of extending a typealias:
> 1) Backwards compatibility — this could very easily break existing code
> 2) Semantically it seems to me that an *alias* is a useful distinction
> from *"let's make a new type" *— sometimes you actually just want to call
> one type by another name in some context
>
> Regardless, I think you could solve your particular problem like this:
>
> public struct HeaderKey {
>    let value: String
>    public init(_ value: String) { self.value = value }
> }
>
> and conform HeaderKey to ExpressibleByStringLiteral. That way your
> framework's users can still use headers[.lastModified] and
> headers["X-MyHeader"] syntax, and it makes your library's code only very
> slightly more complicated.
>
> Not trying to tell you how to write your library, but this approach worked
> really well for me recently.
>
> Best,
>
> Will
>
> On Fri, Jun 9, 2017 at 12:14 AM 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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170609/d10a58c0/attachment.html>