[swift-evolution] Generic Alaises

2016-04-06 Thread James Campbell via swift-evolution
This was inspired from the topic about moving where clauses out of
parameter lists.

Certain generics get very long winded, I was wondering if we could create
some sort of alias for generics.

func anyCommonElements 
(lhs: T, _ rhs: U) -> Bool

could be shared across functions like so:

genericalias SequencesWithSameElements =  

func anyCommonElements  (lhs: T, _ rhs: U) ->
Bool
func ==  (lhs: T, _ rhs: U) -> Bool

*___*

*James⎥*

*ja...@supmenow.com ⎥supmenow.com *

*Sup*

*Runway East *

*10 Finsbury Square*

*London*

* EC2A 1AF *
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


Re: [swift-evolution] Generic Alaises

2016-04-06 Thread Milos Rankovic via swift-evolution
Chris Lattner has a proposal under review 

 on this topic. 

milos

> On 6 Apr 2016, at 20:41, James Campbell via swift-evolution 
>  wrote:
> 
> This was inspired from the topic about moving where clauses out of parameter 
> lists.
> 
> Certain generics get very long winded, I was wondering if we could create 
> some sort of alias for generics.
> 
> func anyCommonElements  T.Generator.Element: Equatable, T.Generator.Element == U.Generator.Element> 
> (lhs: T, _ rhs: U) -> Bool
> 
> could be shared across functions like so:
> 
> genericalias SequencesWithSameElements =   SequenceType where T.Generator.Element: Equatable, T.Generator.Element == 
> U.Generator.Element>
> 
> func anyCommonElements  (lhs: T, _ rhs: U) -> Bool
> func ==  (lhs: T, _ rhs: U) -> Bool
> ___
> 
> James⎥
> 
> ja...@supmenow.com ⎥supmenow.com 
> 
> Sup
> 
> Runway East
> 
> 
> 10 Finsbury Square
> 
> London
> 
> 
> EC2A 1AF 
> 
> ___
> 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


Re: [swift-evolution] Generic Alaises

2016-04-06 Thread Ross O'Brien via swift-evolution
It's not the same topic. Let's take an example: suppose we have a data
structure for a graph of nodes and edges, where the nodes and edges are
indexed and both have values. So we have a Graph.
Now suppose we want a shortest path from one node to another, and we have a
data structure to represent that. Now we have a Path. They both have the same
'generic signature'. If you're navigating a Graph, you're going to want a Path as
output.

Right now you might write that as:
func shortestPath(graph:Graph,
startNode: NodeIndex, endNode: NodeIndex> -> Path

It might save a fair amount of typing if we had a generic equivalent to
both typealias and associatedtype.

associatedgenerics GraphElements = 
func shortestPath(graph: Graph,
startNode, endNode) ->
Path

genericalias NavigationGraphElements = GraphElements

typealias NavigationGraph = Graph
// navigationGraph.shortestPath() now returns a
Path
// this last part is closest to the proposal under review.


On Wed, Apr 6, 2016 at 9:05 PM, Milos Rankovic via swift-evolution <
swift-evolution@swift.org> wrote:

> Chris Lattner has a proposal under review
> 
>  on
> this topic.
>
> milos
>
> On 6 Apr 2016, at 20:41, James Campbell via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> This was inspired from the topic about moving where clauses out of
> parameter lists.
>
> Certain generics get very long winded, I was wondering if we could create
> some sort of alias for generics.
>
> func anyCommonElements  T.Generator.Element: Equatable, T.Generator.Element == U.Generator.Element>
> (lhs: T, _ rhs: U) -> Bool
>
> could be shared across functions like so:
>
> genericalias SequencesWithSameElements =   SequenceType where T.Generator.Element: Equatable, T.Generator.Element ==
> U.Generator.Element>
>
> func anyCommonElements  (lhs: T, _ rhs: U) ->
> Bool
> func ==  (lhs: T, _ rhs: U) -> Bool
>
> *___*
>
> *James⎥*
>
> *ja...@supmenow.com ⎥supmenow.com
> *
>
> *Sup*
>
> *Runway East *
>
> *10 Finsbury Square*
>
> *London*
>
> * EC2A 1AF *
> ___
> 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


Re: [swift-evolution] Generic Alaises

2016-04-06 Thread James Campbell via swift-evolution
Ross put it better than I ever could :) yes this is what I meant 

Sent from Supmenow.com




On Wed, Apr 6, 2016 at 1:45 PM -0700, "Ross O'Brien" 
 wrote:










It's not the same topic. Let's take an example: suppose we have a data 
structure for a graph of nodes and edges, where the nodes and edges are indexed 
and both have values. So we have a Graph.Now suppose we want a shortest path from one 
node to another, and we have a data structure to represent that. Now we have a 
Path. They 
both have the same 'generic signature'. If you're navigating a Graph, you're going to want a Path 
as output.
Right now you might write that as:func shortestPath(graph:Graph, 
startNode: NodeIndex, endNode: NodeIndex> -> Path
It might save a fair amount of typing if we had a generic equivalent to both 
typealias and associatedtype.
associatedgenerics GraphElements = func shortestPath(graph: 
Graph, startNode, 
endNode) -> Path
genericalias NavigationGraphElements = GraphElements
typealias NavigationGraph = Graph// 
navigationGraph.shortestPath() now returns a Path// 
this last part is closest to the proposal under review.

On Wed, Apr 6, 2016 at 9:05 PM, Milos Rankovic via swift-evolution 
 wrote:
Chris Lattner has a proposal under review on this topic. 
milos

On 6 Apr 2016, at 20:41, James Campbell via swift-evolution 
 wrote:
This was inspired from the topic about moving where clauses out of parameter 
lists.
Certain generics get very long winded, I was wondering if we could create some 
sort of alias for generics.
func anyCommonElements  
(lhs: T, _ rhs: U) -> Bool

could be shared across functions like so:
genericalias SequencesWithSameElements =  
func anyCommonElements  (lhs: T, _ rhs: U) -> Bool
func ==  (lhs: T, _ rhs: U) -> Bool


___

James⎥

ja...@supmenow.com⎥supmenow.com

Sup

Runway East


10 Finsbury Square

London


EC2A 1AF 

___
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


Re: [swift-evolution] Generic Alaises

2016-04-06 Thread Milos Rankovic via swift-evolution
Hi Ross,

That was a hell of an example! However, even with the types as they are now, 
the code needn’t look so dreadful. With following protocols in place:

protocol Indexed {
associatedtype Index : Hashable
var index: Index { get }
}

protocol NodeType : Indexed { }
protocol EdgeType: Indexed { }

protocol GraphType {
associatedtype Node : NodeType
associatedtype Edge : EdgeType

var nodes: [Node] { get }
var edges: [Edge] { get }
}

We can define `Graph` and `Path` as:

struct Graph : GraphType {
let nodes: [Node] = [] // todo
let edges: [Edge] = [] // todo
}

struct Path {}

So the function with the endless signature you’ve got would become:

extension Graph {
func shortestPath(from from: Node, to: Node) -> Path {
fatalError("todo")
}
}

As for my link to Chris’s proposal, all I meant is to point out that there is a 
proposal under review with an identical name as this thread. I certainly did 
not mean to discourage discussion James started!

milos

> On 6 Apr 2016, at 21:45, Ross O'Brien  wrote:
> 
> It's not the same topic. Let's take an example: suppose we have a data 
> structure for a graph of nodes and edges, where the nodes and edges are 
> indexed and both have values. So we have a Graph EdgeIndex : Hashable, NodeValue, EdgeValue>.
> Now suppose we want a shortest path from one node to another, and we have a 
> data structure to represent that. Now we have a Path EdgeIndex : Hashable, NodeValue, EdgeValue>. They both have the same 'generic 
> signature'. If you're navigating a Graph, you're 
> going to want a Path as output.
> 
> Right now you might write that as:
> func shortestPath EdgeValue>(graph:Graph, 
> startNode: NodeIndex, endNode: NodeIndex> -> Path NodeValue, EdgeValue>
> 
> It might save a fair amount of typing if we had a generic equivalent to both 
> typealias and associatedtype.
> 
> associatedgenerics GraphElements =  Hashable, NodeValue, EdgeValue>
> func shortestPath(graph: Graph, 
> startNode, endNode) -> 
> Path
> 
> genericalias NavigationGraphElements = GraphElements Motorway>
> 
> typealias NavigationGraph = Graph
> // navigationGraph.shortestPath() now returns a Path
> // this last part is closest to the proposal under review.
> 
> 
> On Wed, Apr 6, 2016 at 9:05 PM, Milos Rankovic via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> Chris Lattner has a proposal under review 
> 
>  on this topic. 
> 
> milos
> 
>> On 6 Apr 2016, at 20:41, James Campbell via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> This was inspired from the topic about moving where clauses out of parameter 
>> lists.
>> 
>> Certain generics get very long winded, I was wondering if we could create 
>> some sort of alias for generics.
>> 
>> func anyCommonElements > T.Generator.Element: Equatable, T.Generator.Element == U.Generator.Element> 
>> (lhs: T, _ rhs: U) -> Bool
>> 
>> could be shared across functions like so:
>> 
>> genericalias SequencesWithSameElements =  > SequenceType where T.Generator.Element: Equatable, T.Generator.Element == 
>> U.Generator.Element>
>> 
>> func anyCommonElements  (lhs: T, _ rhs: U) -> Bool
>> func ==  (lhs: T, _ rhs: U) -> Bool
>> ___
>> 
>> James⎥
>> 
>> ja...@supmenow.com ⎥supmenow.com 
>> 
>> Sup
>> 
>> Runway East
>> 
>> 
>> 10 Finsbury Square
>> 
>> London
>> 
>> 
>> EC2A 1AF 
>> 
>> ___
>> 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