Hello everyone,
To tie into the discussion of shorthands for “map", here’s something that I think is worth considering:
Skipping the motivation (mostly, I’m on a mission to eliminate the $ character in my functional code), here’s a function definition:
func first<A,B>(tuple: (A,B)) -> A {
return tuple.0
}
Having functions like this transforms
pairArray.map({$0.0})
into
pairArray.map(first)
This is not ideal, as it pollutes the global space, and there would need to be tons of those for various tuple sizes.
Here’s an alternative:
pairArray.map(().0)
I think that this makes the intent pretty clear, as well as non-conflicting with anything in the language.
What do you all think?
— Sasha
anandabits
(Matthew Johnson)
2
This is already possible today. You just need to write overloads for tuples of up to n members. Are you asking for this to be a library feature?
···
On Dec 18, 2015, at 9:30 AM, Alexandre Lopoukhine via swift-evolution <swift-evolution@swift.org> wrote:
Hello everyone,
To tie into the discussion of shorthands for “map", here’s something that I think is worth considering:
Skipping the motivation (mostly, I’m on a mission to eliminate the $ character in my functional code), here’s a function definition:
func first<A,B>(tuple: (A,B)) -> A {
return tuple.0
}
Having functions like this transforms
pairArray.map({$0.0})
into
pairArray.map(first)
This is not ideal, as it pollutes the global space, and there would need to be tons of those for various tuple sizes.
Here’s an alternative:
pairArray.map(().0)
I think that this makes the intent pretty clear, as well as non-conflicting with anything in the language.
What do you all think?
— Sasha
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
To consider: the empty tuple expression is currently legal and represents the void value.
···
Le 18 déc. 2015 à 10:30:57, Alexandre Lopoukhine via swift-evolution <swift-evolution@swift.org> a écrit :
Hello everyone,
To tie into the discussion of shorthands for “map", here’s something that I think is worth considering:
Skipping the motivation (mostly, I’m on a mission to eliminate the $ character in my functional code), here’s a function definition:
func first<A,B>(tuple: (A,B)) -> A {
return tuple.0
}
Having functions like this transforms
pairArray.map({$0.0})
into
pairArray.map(first)
This is not ideal, as it pollutes the global space, and there would need to be tons of those for various tuple sizes.
Here’s an alternative:
pairArray.map(().0)
I think that this makes the intent pretty clear, as well as non-conflicting with anything in the language.
What do you all think?
— Sasha
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
Oh, you’re right. The first options I considered were either a global function or a new Tuple class/struct with a bunch of these methods built in, which seemed less elegant but I guess are now the only possibility.
— Sasha
···
On 18 Dec 2015, at 16:36, Félix Cloutier <felixcca@yahoo.ca> wrote:
To consider: the empty tuple expression is currently legal and represents the void value.
Le 18 déc. 2015 à 10:30:57, Alexandre Lopoukhine via swift-evolution <swift-evolution@swift.org> a écrit :
Hello everyone,
To tie into the discussion of shorthands for “map", here’s something that I think is worth considering:
Skipping the motivation (mostly, I’m on a mission to eliminate the $ character in my functional code), here’s a function definition:
func first<A,B>(tuple: (A,B)) -> A {
return tuple.0
}
Having functions like this transforms
pairArray.map({$0.0})
into
pairArray.map(first)
This is not ideal, as it pollutes the global space, and there would need to be tons of those for various tuple sizes.
Here’s an alternative:
pairArray.map(().0)
I think that this makes the intent pretty clear, as well as non-conflicting with anything in the language.
What do you all think?
— Sasha
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
Matthew,
What I’m thinking about would be a true equivalent of the closure syntax, where the following:
{$0.0.1.2} becomes
Tuple.0.1.2
I’m not aware of this being achievable at the language level today.
— Sasha
···
On 18 Dec 2015, at 16:34, Matthew Johnson <matthew@anandabits.com> wrote:
This is already possible today. You just need to write overloads for tuples of up to n members. Are you asking for this to be a library feature?
On Dec 18, 2015, at 9:30 AM, Alexandre Lopoukhine via swift-evolution <swift-evolution@swift.org> wrote:
Hello everyone,
To tie into the discussion of shorthands for “map", here’s something that I think is worth considering:
Skipping the motivation (mostly, I’m on a mission to eliminate the $ character in my functional code), here’s a function definition:
func first<A,B>(tuple: (A,B)) -> A {
return tuple.0
}
Having functions like this transforms
pairArray.map({$0.0})
into
pairArray.map(first)
This is not ideal, as it pollutes the global space, and there would need to be tons of those for various tuple sizes.
Here’s an alternative:
pairArray.map(().0)
I think that this makes the intent pretty clear, as well as non-conflicting with anything in the language.
What do you all think?
— Sasha
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
I think this proposal: [swift-evolution] [Proposal Idea] dot shorthand for instance members would also solve this problem
as you’d be able to do .map(.0), and AFAICT it will still be unambiguous.
— Radek
···
On 18 Dec 2015, at 16:30, Alexandre Lopoukhine via swift-evolution <swift-evolution@swift.org> wrote:
Hello everyone,
To tie into the discussion of shorthands for “map", here’s something that I think is worth considering:
Skipping the motivation (mostly, I’m on a mission to eliminate the $ character in my functional code), here’s a function definition:
func first<A,B>(tuple: (A,B)) -> A {
return tuple.0
}
Having functions like this transforms
pairArray.map({$0.0})
into
pairArray.map(first)
This is not ideal, as it pollutes the global space, and there would need to be tons of those for various tuple sizes.
Here’s an alternative:
pairArray.map(().0)
I think that this makes the intent pretty clear, as well as non-conflicting with anything in the language.
What do you all think?
— Sasha
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
anandabits
(Matthew Johnson)
7
Sorry, I didn’t read your post carefully enough. You are correct, this is not possible.
If you need to dig 3 levels deep into a tuple you may have cases where structs would be more appropriate.
···
On Dec 18, 2015, at 10:01 AM, Alexandre Lopoukhine <superlopuh@gmail.com> wrote:
Matthew,
What I’m thinking about would be a true equivalent of the closure syntax, where the following:
{$0.0.1.2} becomes
Tuple.0.1.2
I’m not aware of this being achievable at the language level today.
— Sasha
On 18 Dec 2015, at 16:34, Matthew Johnson <matthew@anandabits.com> wrote:
This is already possible today. You just need to write overloads for tuples of up to n members. Are you asking for this to be a library feature?
On Dec 18, 2015, at 9:30 AM, Alexandre Lopoukhine via swift-evolution <swift-evolution@swift.org> wrote:
Hello everyone,
To tie into the discussion of shorthands for “map", here’s something that I think is worth considering:
Skipping the motivation (mostly, I’m on a mission to eliminate the $ character in my functional code), here’s a function definition:
func first<A,B>(tuple: (A,B)) -> A {
return tuple.0
}
Having functions like this transforms
pairArray.map({$0.0})
into
pairArray.map(first)
This is not ideal, as it pollutes the global space, and there would need to be tons of those for various tuple sizes.
Here’s an alternative:
pairArray.map(().0)
I think that this makes the intent pretty clear, as well as non-conflicting with anything in the language.
What do you all think?
— Sasha
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
