Will these two features be included in Swift 3?

Tuuranton · December 7, 2015, 11:40am

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

Daniel_Steinberg · December 7, 2015, 1:53pm

I would love to see this feature if it is possible. You can’t currently create an extension on Array<Double> so a common work-around is to add your functionality to SequenceType where you constrain the Generator’s Element to be of type Double - this means I’ve added functionality in places beyond where it belongs.

Daniel

···

On Dec 7, 2015, at 6:40 AM, Tuur Anton via swift-evolution <swift-evolution@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
}

Krzysztof_Siejkowski · December 7, 2015, 12:01pm

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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Krzysztof_Siejkowski · December 7, 2015, 12:14pm

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

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 13:01:11, Krzysztof Siejkowski (krzysztof@siejkowski.net) wrote:

On 7 December 2015 at 12:41:05, Tuur Anton via swift-evolution (swift-evolution@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Joe_Groff · December 7, 2015, 7:05pm

I thought constraining an extension to a single type (#1) was already in 2.2?
I've seen it in a SPM example and also someone confirmed to me that it compiled

It went like
extension Array where Element == Double { // add stuff }

This ought to work, but doesn't because of a bug we didn't get around to fixing.

-Joe

···

On Dec 7, 2015, at 4:34 AM, Davide De Franceschi via swift-evolution <swift-evolution@swift.org> wrote:

On 7 Dec 2015, at 12:14, Krzysztof Siejkowski via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

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@siejkowski.net <mailto:krzysztof@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
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 <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

DeFrenZ · December 7, 2015, 12:34pm

I thought constraining an extension to a single type (#1) was already in 2.2?
I've seen it in a SPM example and also someone confirmed to me that it compiled

It went like
extension Array where Element == Double { // add stuff }

···

On 7 Dec 2015, at 12:14, Krzysztof Siejkowski via swift-evolution <swift-evolution@swift.org> wrote:

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@siejkowski.net <mailto:krzysztof@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

Krzysztof_Siejkowski · December 7, 2015, 12:56pm

Oh, it could be so, I’m just not aware of it. I’ve tried Swift version 2.2-dev (LLVM 46be9ff861, Clang 4deb154edc, Swift 778f82939c) with

extension Array where Element == Double {
func foo() -> String {
return "hello doubles!"
}
}

and got

repl.swift:1:31: error: same-type requirement makes generic parameter 'Element' non-generic
extension Array where Element == Double {
^

Could you please point to docs / example / reference?

All the best,
Krzysztof

I thought constraining an extension to a single type (#1) was already in 2.2?
I've seen it in a SPM example and also someone confirmed to me that it compiled

It went like
extension Array where Element == Double { // add stuff }

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

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 13:34:51, Davide De Franceschi via swift-evolution (swift-evolution@swift.org) wrote:
On 7 Dec 2015, at 12:14, Krzysztof Siejkowski via swift-evolution <swift-evolution@swift.org> wrote:
On 7 December 2015 at 13:01:11, Krzysztof Siejkowski (krzysztof@siejkowski.net) wrote:

On 7 December 2015 at 12:41:05, Tuur Anton via swift-evolution (swift-evolution@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@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

Tuuranton · December 8, 2015, 12:04pm

However, I personally like the idea of making a syntactic sugar for that
case.

Thanks! I didn't know I could do it like that.Yeah, someone please add that
syntactic sugar. That would be really cool. Otherwise my namespace gets
polluted with that DoubleProtocol, minor drawback :)

···

--
Securely sent with Tutanota. Claim your encrypted mailbox today!

7. Dec 2015 13:14 by krzysztof@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@siejkowski.net> ) wrote:

Concerning generic typealiases, the topic is already beingdiscussed in
„Generic `typealias`s” thread: >
https://lists.swift.org/pipermail/swift-evolution/2015-December/000132.html>
.The core Swift team approves:
> > Yes, this isdefinitely something that I (at least) would like to see.
Patcheswelcome :-)> > Chris(Lattner)
All the best,> Krzysztof

On 7 December 2015 at 12:41:05, Tuur Antonvia swift-evolution (> > swift-evolution@swift.org> )wrote:

Can you please add these features in Swift3?
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:
>> }>> typealias IntFoo<V> = Foo<Int,V> //Error inSwift 2.1>>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Tuuranton · December 8, 2015, 9:26pm

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!

7. Dec 2015 13:14 by krzysztof@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@siejkowski.net> ) wrote:

Concerning generic typealiases, the topic is already beingdiscussed in
„Generic `typealias`s” thread: >
https://lists.swift.org/pipermail/swift-evolution/2015-December/000132.html>
.The core Swift team approves:
> > Yes, this isdefinitely something that I (at least) would like to see.
Patcheswelcome :-)> > Chris(Lattner)
All the best,> Krzysztof

On 7 December 2015 at 12:41:05, Tuur Antonvia swift-evolution (> > swift-evolution@swift.org> )wrote:

Can you please add these features in Swift3?
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:
>> }>> typealias IntFoo<V> = Foo<Int,V> //Error inSwift 2.1>>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Slava_Pestov · December 7, 2015, 7:06pm

Oh, it could be so, I’m just not aware of it. I’ve tried Swift version 2.2-dev (LLVM 46be9ff861, Clang 4deb154edc, Swift 778f82939c) with

extension Array where Element == Double {
     func foo() -> String {
         return "hello doubles!"
     }
}

and got

repl.swift:1:31: error: same-type requirement makes generic parameter 'Element' non-generic
extension Array where Element == Double {
                              ^

This is an artificial limitation.

In the case of a generic signature of a function, you really *do* want to prevent the user from constraining parameters to the point of becoming non-generic, eg the following does not make sense:

func foo<T where T == Int>(t: T) // why not just say func foo(t: Int) instead?

However the same diagnostic logic is used for validating generic signatures of constrained extensions, when in fact it needs a slightly different set of checks.

I think this is something that a community member could figure out and fix pretty easily without going through the evolution process -- its really a language change at this point.

Slava

···

On Dec 7, 2015, at 4:56 AM, Krzysztof Siejkowski via swift-evolution <swift-evolution@swift.org> wrote:

Could you please point to docs / example / reference?

All the best,
Krzysztof

On 7 December 2015 at 13:34:51, Davide De Franceschi via swift-evolution (swift-evolution@swift.org <mailto:swift-evolution@swift.org>) wrote:
I thought constraining an extension to a single type (#1) was already in 2.2?
I've seen it in a SPM example and also someone confirmed to me that it compiled

It went like
extension Array where Element == Double { // add stuff }
On 7 Dec 2015, at 12:14, Krzysztof Siejkowski via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

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@siejkowski.net <mailto:krzysztof@siejkowski.net>) wrote:

Concerning generic typealiases, the topic is already being discussed in „Generic `typealias`s” thread: [swift-evolution] Generic `typealias`s <[swift-evolution] Generic `typealias`s. 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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.swift.org_mailman_listinfo_swift-2Devolution&d=BQMFaQ&c=Hw-EJUFt2_D9PK5csBJ29kRV40HqSDXWTLPyZ6W8u84&r=Uu9iNLnY0h1pMgusxPvGAdQh7wn-fCLNd0vIsJCqWtk&m=Uzu4AUxAPExJgD7SwlP-qUxaoP5S2zFxkNZqp8nUDN0&s=DDvpZ11cAh4tJzwSrC_Znf-_EuEh9_qzIeYp3oCdOyg&e=>

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.swift.org_mailman_listinfo_swift-2Devolution&d=BQMFaQ&c=Hw-EJUFt2_D9PK5csBJ29kRV40HqSDXWTLPyZ6W8u84&r=Uu9iNLnY0h1pMgusxPvGAdQh7wn-fCLNd0vIsJCqWtk&m=Uzu4AUxAPExJgD7SwlP-qUxaoP5S2zFxkNZqp8nUDN0&s=DDvpZ11cAh4tJzwSrC_Znf-_EuEh9_qzIeYp3oCdOyg&e=>
_______________________________________________
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 <mailto:swift-evolution@swift.org>
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.swift.org_mailman_listinfo_swift-2Devolution&d=BQIGaQ&c=Hw-EJUFt2_D9PK5csBJ29kRV40HqSDXWTLPyZ6W8u84&r=Uu9iNLnY0h1pMgusxPvGAdQh7wn-fCLNd0vIsJCqWtk&m=Uzu4AUxAPExJgD7SwlP-qUxaoP5S2zFxkNZqp8nUDN0&s=DDvpZ11cAh4tJzwSrC_Znf-_EuEh9_qzIeYp3oCdOyg&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.swift.org_mailman_listinfo_swift-2Devolution&d=BQIGaQ&c=Hw-EJUFt2_D9PK5csBJ29kRV40HqSDXWTLPyZ6W8u84&r=Uu9iNLnY0h1pMgusxPvGAdQh7wn-fCLNd0vIsJCqWtk&m=Uzu4AUxAPExJgD7SwlP-qUxaoP5S2zFxkNZqp8nUDN0&s=DDvpZ11cAh4tJzwSrC_Znf-_EuEh9_qzIeYp3oCdOyg&e=>

jtbandes · December 7, 2015, 7:11pm

I'd be interested in working on fixing this, though I won't be able to get
started immediately, so if someone else is more eager, go for it :-D

Jacob Bandes-Storch

···

On Mon, Dec 7, 2015 at 11:06 AM, Slava Pestov via swift-evolution < swift-evolution@swift.org> wrote:

However the same diagnostic logic is used for validating generic
signatures of constrained extensions, when in fact it needs a slightly
different set of checks.

I think this is something that a community member could figure out and fix
pretty easily without going through the evolution process -- its really a
language change at this point.

Slava

DeFrenZ · December 7, 2015, 1:17pm

So, I got now that I was confused.

When I saw this:
https://github.com/apple/example-package-fisheryates/blob/master/Sources/Fisher-Yates_Shuffle.swift#L26
I was surprised as I was pretty sure you couldn't do that. But it works in 2.1 as well.

But it's extending a protocol, not a type.

but it still means that you can do what you wanted with
extension SequenceType where Generator.Element == Double {
  func foo() -> String {
    return "hello doubles!"
  }
}

(of course there are cases where the type is generic but it doesn't adopt a protocol with associated types to extend, so it's still plenty useful)

···

On 7 Dec 2015, at 12:56, Krzysztof Siejkowski <krzysztof@siejkowski.net> wrote:

Oh, it could be so, I’m just not aware of it. I’ve tried Swift version 2.2-dev (LLVM 46be9ff861, Clang 4deb154edc, Swift 778f82939c) with

extension Array where Element == Double {
     func foo() -> String {
         return "hello doubles!"
     }
}

and got

repl.swift:1:31: error: same-type requirement makes generic parameter 'Element' non-generic
extension Array where Element == Double {
                              ^

Could you please point to docs / example / reference?

All the best,
Krzysztof

On 7 December 2015 at 13:34:51, Davide De Franceschi via swift-evolution (swift-evolution@swift.org <mailto:swift-evolution@swift.org>) wrote:
I thought constraining an extension to a single type (#1) was already in 2.2?
I've seen it in a SPM example and also someone confirmed to me that it compiled

It went like
extension Array where Element == Double { // add stuff }
On 7 Dec 2015, at 12:14, Krzysztof Siejkowski via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

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@siejkowski.net <mailto:krzysztof@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
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 <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

Simon_Pilkington1 · December 8, 2015, 3:41pm

Jacob,

When do you think you’d get to it? I’d be interested in looking at it as long as I’m not stepping on your toes.

Cheers,
Simon

···

On 7 Dec 2015, at 11:11 AM, Jacob Bandes-Storch via swift-evolution <swift-evolution@swift.org> wrote:

On Mon, Dec 7, 2015 at 11:06 AM, Slava Pestov via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

However the same diagnostic logic is used for validating generic signatures of constrained extensions, when in fact it needs a slightly different set of checks.

I think this is something that a community member could figure out and fix pretty easily without going through the evolution process -- its really a language change at this point.

Slava

I'd be interested in working on fixing this, though I won't be able to get started immediately, so if someone else is more eager, go for it :-D

Jacob Bandes-Storch
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Alex_Lew · December 8, 2015, 10:19pm

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@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@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@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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Untracked with Trackbuster <Your contacts automatically up to date | evercontact;

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Krzysztof_Siejkowski · December 9, 2015, 6:01am

True. DoubleProtocol introduces a layer of indirection.

This might be a disadvantage, because it requires unnecessary verbosity of the casting to original type. It also might be useful, because it allows you to pick and choose only the subset of functionalities and ensure the method of Array extension won’t have an access to all the abilities the type provides. It’s basically a mask for the interface of original type.

protocol DoubleType {
var isFinite: Bool { get }
}

extension Double : DoubleType {
var isFinite: Bool { get {
return self.isFinite
}}
}

extension Array where Element : DoubleType {
func onlyFiniteAllowed() -> [Element] {
return self.filter { $0.isFinite } // I know nothing about $0 but if it’s finite
}
}

Anyway, it looks like plain’n’simple extension Array Element == Double is already on its way, thanks to Simon and Jakob :)

···

-----Original Message-----
From: Alex Lew <alexl.mail+swift@gmail.com>
Reply: Alex Lew <alexl.mail+swift@gmail.com>
Date: December 8, 2015 at 11:19:41 PM
To: tuuranton@tutanota.de <tuuranton@tutanota.de>
CC: Krzysztof Siejkowski <krzysztof@siejkowski.net>, Swift Evolution <swift-evolution@swift.org>
Subject: Re: [swift-evolution] Will these two features be included in Swift 3?

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@swift.org> wrote:

> Actually, I just realized that your solution isn't at all what I'm after.
>
> Doing "extension Array" 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" 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@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@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@swift.org) wrote:
>
> Can you please add these features in Swift 3?
>
> 1. The ability to do this:
> extension Array {
> //extend arrays of doubles
> }
>
> 2. Generic typealiases:
> struct Foo {
> let t: T
> let v: V
> }
> typealias IntFoo = Foo //Error in Swift 2.1
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> Untracked with Trackbuster
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>