[swift-evolution] Will these two features be included in Swift 3?

[Alex Lew]

I think the pattern here is

protocol DoubleProtocol {
     var doubleValue: Double { get }
}
extension Double: DoubleProtocol {
     var doubleValue: Double { return self }
}
extension Array where Element: DoubleProtocol {
     // in these methods, use the element's .doubleValue property
     // to get the actual double, on which you can then call Double's
methods
}

That way, if another type wants to conform to DoubleProtocol, it needs to
be able to represent itself as a Double.

-Alex

On Tue, Dec 8, 2015 at 4:26 PM, Tuur Anton via swift-evolution <
swift-evolution at swift.org> wrote:

> Actually, I just realized that your solution isn't at all what I'm after.
>
> Doing "extension Array<Double>" is not the same thing and wouldn't be just
> a "syntactic sugar" for the code you came up with.
>
> Why? Because in your code, the extension method only knows that the
> array's Element is a DoubleProtocol. It doesn't know it's a *Double* (which
> is what I want it to be). As such, it won't have access to Double's methods
> and such.
>
> This is probably okay for Doubles, but for other types, especially my own
> custom types with their own methods, the difference is huge. "extension
> Array<MyStructType>" is what I want, but your solution won't help me if the
> extension method needs access to MyStructType's methods.
>
> See what I mean, or am I missing something here?
>
> --
> Securely sent with Tutanota. Claim your encrypted mailbox today!
> https://tutanota.com
>
> 7. Dec 2015 13:14 by krzysztof at siejkowski.net:
>
> Concerning extension constraining, it’s already doable with:
>
> ```
> protocol DoubleProtocol {}
>
> extension Double : DoubleProtocol {}
>
> extension Array where Element : DoubleProtocol {
>     func onlyForDoubles() -> String {
>             return "hello doubles!"
>     }
> }
>
> [1.2].onlyForDoubles() // „hello doubles!”
> ["a"].onlyForDoubles() // error: type of expression is ambiguous without
> more context
> ```
>
> However, I personally like the idea of making a syntactic sugar for that
> case.
>
> All the best,
> Krzysztof
>
>
> On 7 December 2015 at 13:01:11, Krzysztof Siejkowski (
> krzysztof at siejkowski.net) wrote:
>
> Concerning generic typealiases, the topic is already being discussed in
> „Generic `typealias`s” thread:
> https://lists.swift.org/pipermail/swift-evolution/2015-December/000132.html.
> The core Swift team approves:
>
> >  Yes, this is definitely something that I (at least) would like to see.
> Patches welcome :-)
> > Chris (Lattner)
>
> All the best,
> Krzysztof
>
> On 7 December 2015 at 12:41:05, Tuur Anton via swift-evolution (
> swift-evolution at swift.org) wrote:
>
> Can you please add these features in Swift 3?
>
> 1. The ability to do this:
> extension Array<Double> {
>     //extend arrays of doubles
> }
>
> 2. Generic typealiases:
> struct Foo<T,V> {
>     let t: T
>     let v: V
> }
> typealias IntFoo<V> = Foo<Int,V> //Error in Swift 2.1
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> Untracked with Trackbuster <https://trackbuster.com/?sig>
>
> _______________________________________________
> 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/20151208/5b205e28/attachment.html>