Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Joe Groff via swift-evolution]

> On Nov 28, 2017, at 8:33 PM, Tony Allevato  wrote:
> 
> On Tue, Nov 28, 2017 at 11:23 AM Kelvin Ma via swift-evolution 
>  wrote:
> On Tue, Nov 28, 2017 at 12:59 PM, Joe Groff via swift-evolution 
>  wrote:
> 
> 
> > On Nov 28, 2017, at 10:52 AM, Vladimir.S  wrote:
> >
> > On 27.11.2017 20:28, Joe Groff via swift-evolution wrote:
> >>> On Nov 20, 2017, at 5:43 PM, Chris Lattner via swift-evolution 
> >>> > wrote:
> >>>
> >>>
>  On Nov 20, 2017, at 5:39 PM, Kelvin Ma via swift-evolution 
>  > wrote:
> 
>  when SE-185 
>  
>   went through swift evolution, it was agreed that the next logical step 
>   
>  is synthesizing these conformances for tuple types, though it was left 
>  out of the original proposal to avoid mission creep. I think now is the 
>  time to start thinking about this. i’m also tacking on Comparable to the 
>  other two protocols because there is precedent in the language from 
>  SE-15 
>  
>   that tuple comparison is something that makes sense to write.
> 
>  EHC conformance is even more important for tuples than it is for structs 
>  because tuples effectively have no workaround whereas in structs, you 
>  could just manually implement the conformance.
> >>>
> >>> In my opinion, you’re approaching this from the wrong direction.  The 
> >>> fundamental problem here is that tuples can’t conform to a protocol.  If 
> >>> they could, synthesizing these conformances would be straight-forward.
> >> It would be a tractable intermediate problem to introduce built-in 
> >> conformances for tuples (and perhaps metatypes) to 
> >> Equatable/Hashable/Comparable without breaching the more general topic of 
> >> allowing these types to have general protocol conformances. I think that 
> >> would cover the highest-value use cases.
> >
> > So, shouldn't we do this first step ASAP and then design a good common 
> > solution to allow tuples/metatypes/funcs to confirm to custom protocols in 
> > some next version of Swift?
> > I really believe this is the good practical decision and will be supported 
> > by community if such proposal will be on the table.
> > Is there any drawback in such step?
> 
> The expected behavior of tuple Equatable/Hashable/Comparable seems obvious to 
> me (though I could well be missing something), and any behavior we hardcode 
> should be naturally replaceable by a generalized conformance mechanism, so 
> it's primarily a "small matter of implementation". There would be some 
> implementation cost to managing the special case in the compiler and runtime; 
> the tradeoff seems worth it to me in this case, but others might reasonably 
> disagree. Not speaking for the entire core team, I would personally support 
> considering a proposal and implementation for builtin tuple 
> Equatable/Hashable/Comparable conformance.
> 
> -Joe
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> i wouldn’t know how to implement this but i could write up this proposal in a 
> few days 
> 
> I've been looking the past couple days at how to generalize the protocol 
> conformance machinery to support structural types (even if we don't support 
> arbitrary conformance syntactically, at least being able to hardcode the ones 
> we want to synthesize initially). My free time isn't exactly plentiful, but 
> I'm hoping to make some decent progress, so I'm happy to help where I can on 
> this since it's a natural follow-up to my other Equatable/Hashable work!

If I were going to look into implementing this, my first-pass approach would be 
something like this. It's not necessarily the best or most optimal approach, 
but it might get you started:

- Introduce a new ProtocolConformance subclass for tuple conformances, that 
collects the required protocol conformances from all the elements
- Enhance the AST and type checker conformance lookup machinery, such as 
lookupConformance and conformsToProtocol, to work with tuples, by returning 
TupleProtocolConformances where applicable
- In IRGen, lower a reference to a TupleProtocolConformance into a runtime call 
that grabs the conformance for a tuple type to a given protocol with the given 
element conformances
- In the runtime, implement these runtime calls similar to how we generate 
structural type metadata, with a uniquing cache that instantiates a unique 
witness table for each 

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Tony Allevato via swift-evolution]

On Tue, Nov 28, 2017 at 11:23 AM Kelvin Ma via swift-evolution <
swift-evolution@swift.org> wrote:

> On Tue, Nov 28, 2017 at 12:59 PM, Joe Groff via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>>
>> > On Nov 28, 2017, at 10:52 AM, Vladimir.S  wrote:
>> >
>> > On 27.11.2017 20:28, Joe Groff via swift-evolution wrote:
>> >>> On Nov 20, 2017, at 5:43 PM, Chris Lattner via swift-evolution <
>> swift-evolution@swift.org > wrote:
>> >>>
>> >>>
>>  On Nov 20, 2017, at 5:39 PM, Kelvin Ma via swift-evolution <
>> swift-evolution@swift.org > wrote:
>> 
>>  when SE-185 <
>> https://github.com/apple/swift-evolution/blob/master/proposals/0185-synthesize-equatable-hashable.md>
>> went through swift evolution, it was agreed that the next logical step <
>> https://www.mail-archive.com/swift-evolution@swift.org/msg26162.html> is
>> synthesizing these conformances for tuple types, though it was left out of
>> the original proposal to avoid mission creep. I think now is the time to
>> start thinking about this. i’m also tacking on Comparable to the other two
>> protocols because there is precedent in the language from SE-15 <
>> https://github.com/apple/swift-evolution/blob/master/proposals/0015-tuple-comparison-operators.md>
>> that tuple comparison is something that makes sense to write.
>> 
>>  EHC conformance is even more important for tuples than it is for
>> structs because tuples effectively have no workaround whereas in structs,
>> you could just manually implement the conformance.
>> >>>
>> >>> In my opinion, you’re approaching this from the wrong direction.  The
>> fundamental problem here is that tuples can’t conform to a protocol.  If
>> they could, synthesizing these conformances would be straight-forward.
>> >> It would be a tractable intermediate problem to introduce built-in
>> conformances for tuples (and perhaps metatypes) to
>> Equatable/Hashable/Comparable without breaching the more general topic of
>> allowing these types to have general protocol conformances. I think that
>> would cover the highest-value use cases.
>> >
>> > So, shouldn't we do this first step ASAP and then design a good common
>> solution to allow tuples/metatypes/funcs to confirm to custom protocols in
>> some next version of Swift?
>> > I really believe this is the good practical decision and will be
>> supported by community if such proposal will be on the table.
>> > Is there any drawback in such step?
>>
>> The expected behavior of tuple Equatable/Hashable/Comparable seems
>> obvious to me (though I could well be missing something), and any behavior
>> we hardcode should be naturally replaceable by a generalized conformance
>> mechanism, so it's primarily a "small matter of implementation". There
>> would be some implementation cost to managing the special case in the
>> compiler and runtime; the tradeoff seems worth it to me in this case, but
>> others might reasonably disagree. Not speaking for the entire core team, I
>> would personally support considering a proposal and implementation for
>> builtin tuple Equatable/Hashable/Comparable conformance.
>>
>> -Joe
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
> i wouldn’t know how to implement this but i could write up this proposal
> in a few days
>

I've been looking the past couple days at how to generalize the protocol
conformance machinery to support structural types (even if we don't support
arbitrary conformance syntactically, at least being able to hardcode the
ones we want to synthesize initially). My free time isn't exactly
plentiful, but I'm hoping to make some decent progress, so I'm happy to
help where I can on this since it's a natural follow-up to my other
Equatable/Hashable work!


>
> ___
> 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] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Jonathan Hull via swift-evolution]

+1.  It seems like a practical first step.

> On Nov 28, 2017, at 10:59 AM, Joe Groff via swift-evolution 
>  wrote:
> 
> 
> 
>> On Nov 28, 2017, at 10:52 AM, Vladimir.S  wrote:
>> 
>> On 27.11.2017 20:28, Joe Groff via swift-evolution wrote:
 On Nov 20, 2017, at 5:43 PM, Chris Lattner via swift-evolution 
 > wrote:
 
 
> On Nov 20, 2017, at 5:39 PM, Kelvin Ma via swift-evolution 
> > wrote:
> 
> when SE-185 
> 
>  went through swift evolution, it was agreed that the next logical step 
>  is 
> synthesizing these conformances for tuple types, though it was left out 
> of the original proposal to avoid mission creep. I think now is the time 
> to start thinking about this. i’m also tacking on Comparable to the other 
> two protocols because there is precedent in the language from SE-15 
> 
>  that tuple comparison is something that makes sense to write.
> 
> EHC conformance is even more important for tuples than it is for structs 
> because tuples effectively have no workaround whereas in structs, you 
> could just manually implement the conformance. 
 
 In my opinion, you’re approaching this from the wrong direction.  The 
 fundamental problem here is that tuples can’t conform to a protocol.  If 
 they could, synthesizing these conformances would be straight-forward.
>>> It would be a tractable intermediate problem to introduce built-in 
>>> conformances for tuples (and perhaps metatypes) to 
>>> Equatable/Hashable/Comparable without breaching the more general topic of 
>>> allowing these types to have general protocol conformances. I think that 
>>> would cover the highest-value use cases.
>> 
>> So, shouldn't we do this first step ASAP and then design a good common 
>> solution to allow tuples/metatypes/funcs to confirm to custom protocols in 
>> some next version of Swift?
>> I really believe this is the good practical decision and will be supported 
>> by community if such proposal will be on the table.
>> Is there any drawback in such step?
> 
> The expected behavior of tuple Equatable/Hashable/Comparable seems obvious to 
> me (though I could well be missing something), and any behavior we hardcode 
> should be naturally replaceable by a generalized conformance mechanism, so 
> it's primarily a "small matter of implementation". There would be some 
> implementation cost to managing the special case in the compiler and runtime; 
> the tradeoff seems worth it to me in this case, but others might reasonably 
> disagree. Not speaking for the entire core team, I would personally support 
> considering a proposal and implementation for builtin tuple 
> Equatable/Hashable/Comparable conformance.
> 
> -Joe
> ___
> 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] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Kelvin Ma via swift-evolution]

On Tue, Nov 28, 2017 at 12:59 PM, Joe Groff via swift-evolution <
swift-evolution@swift.org> wrote:

>
>
> > On Nov 28, 2017, at 10:52 AM, Vladimir.S  wrote:
> >
> > On 27.11.2017 20:28, Joe Groff via swift-evolution wrote:
> >>> On Nov 20, 2017, at 5:43 PM, Chris Lattner via swift-evolution <
> swift-evolution@swift.org > wrote:
> >>>
> >>>
>  On Nov 20, 2017, at 5:39 PM, Kelvin Ma via swift-evolution <
> swift-evolution@swift.org > wrote:
> 
>  when SE-185  proposals/0185-synthesize-equatable-hashable.md> went through swift
> evolution, it was agreed that the next logical step <
> https://www.mail-archive.com/swift-evolution@swift.org/msg26162.html> is
> synthesizing these conformances for tuple types, though it was left out of
> the original proposal to avoid mission creep. I think now is the time to
> start thinking about this. i’m also tacking on Comparable to the other two
> protocols because there is precedent in the language from SE-15 <
> https://github.com/apple/swift-evolution/blob/master/proposals/0015-tuple-
> comparison-operators.md> that tuple comparison is something that makes
> sense to write.
> 
>  EHC conformance is even more important for tuples than it is for
> structs because tuples effectively have no workaround whereas in structs,
> you could just manually implement the conformance.
> >>>
> >>> In my opinion, you’re approaching this from the wrong direction.  The
> fundamental problem here is that tuples can’t conform to a protocol.  If
> they could, synthesizing these conformances would be straight-forward.
> >> It would be a tractable intermediate problem to introduce built-in
> conformances for tuples (and perhaps metatypes) to
> Equatable/Hashable/Comparable without breaching the more general topic of
> allowing these types to have general protocol conformances. I think that
> would cover the highest-value use cases.
> >
> > So, shouldn't we do this first step ASAP and then design a good common
> solution to allow tuples/metatypes/funcs to confirm to custom protocols in
> some next version of Swift?
> > I really believe this is the good practical decision and will be
> supported by community if such proposal will be on the table.
> > Is there any drawback in such step?
>
> The expected behavior of tuple Equatable/Hashable/Comparable seems obvious
> to me (though I could well be missing something), and any behavior we
> hardcode should be naturally replaceable by a generalized conformance
> mechanism, so it's primarily a "small matter of implementation". There
> would be some implementation cost to managing the special case in the
> compiler and runtime; the tradeoff seems worth it to me in this case, but
> others might reasonably disagree. Not speaking for the entire core team, I
> would personally support considering a proposal and implementation for
> builtin tuple Equatable/Hashable/Comparable conformance.
>
> -Joe
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>

i wouldn’t know how to implement this but i could write up this proposal in
a few days
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Kelvin Ma via swift-evolution]

On Tue, Nov 28, 2017 at 3:18 AM, Xiaodi Wu  wrote:

>
> On Tue, Nov 28, 2017 at 00:32 Kelvin Ma  wrote:
>
>> On Mon, Nov 27, 2017 at 9:43 PM, Xiaodi Wu  wrote:
>>
>>> On Mon, Nov 27, 2017 at 5:56 PM, Kelvin Ma  wrote:
>>>


 On Mon, Nov 27, 2017 at 4:21 PM, Xiaodi Wu  wrote:

> On Mon, Nov 27, 2017 at 15:46 Taylor Swift 
> wrote:
>
>> they use packed buffers of floats, which for type safety are better
>> rebound to a structured type. right now (Float, Float, Float) works 
>> because
>> the tuple is laid out contiguously and the GPU can’t tell the difference
>> but it’s not guaranteed. also you’re ignoring all the CPU stages that 
>> occur
>> before anything even gets sent to the GPU.
>>
>
> Precisely, there is no guarantee of performance if you call these APIs
> with an array of Swift tuples.
>

 which is exactly why i support a dedicated language-level vector type
 which guarantees contiguous, fixed storage, and which the compiler knows
 about so it can vectorize operations on them.

>>>
>>> That's an entirely separate discussion.
>>>
>>>
 tuples right now try to fill too many roles and that makes life
 difficult for both the compiler and the programmer. however, until then, we
 need some kind of common, fixed layout currency type for vector data, and
 by implementation-detail, *tuples are our best option* since for some
 reason everyone is so opposed to the simple solution of baking vec2,
 vec3, … vec5 into the language and the generic integer Vector
 solution everyone wants likely isn’t going to materialize for the
 foreseeable future.

>>>
>>> Disagree. If you want a particular memory layout, define your type in C.
>>> Swift's interop story is very good, and your type will have a fixed layout
>>> forever.
>>>
>>
>> “*write it in c and import it*” is *not* a solution,, it is a workaround.
>>
>
> Yes, that’s what we’re talking about here: workarounds to lack of a fixed
> layout type. I’m saying C is the “best option” workaround, not tuples.
>
> plus since it lives across the module boundary, it’s effectively opaque to
>> compiler optimizations.
>>
> What sorts of optimizations are you referring to? Recall that we are
> talking about taking a value and unsafe bitcasting for the purposes of
> calling other C APIs.
>
> you misunderstand the use-case. C and C APIs usually don’t show up in the
story until the very last step, when you send the buffer to the drawing
library (cairo, opengl, etc). all the stages that come before are swift and
involve passing data between two swift interfaces.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Joe Groff via swift-evolution]

> On Nov 28, 2017, at 10:52 AM, Vladimir.S  wrote:
> 
> On 27.11.2017 20:28, Joe Groff via swift-evolution wrote:
>>> On Nov 20, 2017, at 5:43 PM, Chris Lattner via swift-evolution 
>>> > wrote:
>>> 
>>> 
 On Nov 20, 2017, at 5:39 PM, Kelvin Ma via swift-evolution 
 > wrote:
 
 when SE-185 
 
  went through swift evolution, it was agreed that the next logical step 
  is 
 synthesizing these conformances for tuple types, though it was left out of 
 the original proposal to avoid mission creep. I think now is the time to 
 start thinking about this. i’m also tacking on Comparable to the other two 
 protocols because there is precedent in the language from SE-15 
 
  that tuple comparison is something that makes sense to write.
 
 EHC conformance is even more important for tuples than it is for structs 
 because tuples effectively have no workaround whereas in structs, you 
 could just manually implement the conformance. 
>>> 
>>> In my opinion, you’re approaching this from the wrong direction.  The 
>>> fundamental problem here is that tuples can’t conform to a protocol.  If 
>>> they could, synthesizing these conformances would be straight-forward.
>> It would be a tractable intermediate problem to introduce built-in 
>> conformances for tuples (and perhaps metatypes) to 
>> Equatable/Hashable/Comparable without breaching the more general topic of 
>> allowing these types to have general protocol conformances. I think that 
>> would cover the highest-value use cases.
> 
> So, shouldn't we do this first step ASAP and then design a good common 
> solution to allow tuples/metatypes/funcs to confirm to custom protocols in 
> some next version of Swift?
> I really believe this is the good practical decision and will be supported by 
> community if such proposal will be on the table.
> Is there any drawback in such step?

The expected behavior of tuple Equatable/Hashable/Comparable seems obvious to 
me (though I could well be missing something), and any behavior we hardcode 
should be naturally replaceable by a generalized conformance mechanism, so it's 
primarily a "small matter of implementation". There would be some 
implementation cost to managing the special case in the compiler and runtime; 
the tradeoff seems worth it to me in this case, but others might reasonably 
disagree. Not speaking for the entire core team, I would personally support 
considering a proposal and implementation for builtin tuple 
Equatable/Hashable/Comparable conformance.

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

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Vladimir.S via swift-evolution]

On 27.11.2017 20:28, Joe Groff via swift-evolution wrote:



On Nov 20, 2017, at 5:43 PM, Chris Lattner via swift-evolution > wrote:



On Nov 20, 2017, at 5:39 PM, Kelvin Ma via swift-evolution > wrote:


when SE-185  
went through swift evolution, it was agreed that the next logical step 
 is synthesizing these conformances for tuple 
types, though it was left out of the original proposal to avoid mission creep. I think now is the time to start 
thinking about this. i’m also tacking on Comparable to the other two protocols because there is precedent in the 
language from SE-15 
 that tuple 
comparison is something that makes sense to write.


EHC conformance is even more important for tuples than it is for structs because tuples effectively have no 
workaround whereas in structs, you could just manually implement the conformance. 


In my opinion, you’re approaching this from the wrong direction.  The fundamental problem here is that tuples can’t 
conform to a protocol.  If they could, synthesizing these conformances would be straight-forward.


It would be a tractable intermediate problem to introduce built-in conformances for tuples (and perhaps metatypes) to 
Equatable/Hashable/Comparable without breaching the more general topic of allowing these types to have general protocol 
conformances. I think that would cover the highest-value use cases.


So, shouldn't we do this first step ASAP and then design a good common solution to allow tuples/metatypes/funcs to 
confirm to custom protocols in some next version of Swift?
I really believe this is the good practical decision and will be supported by community if such proposal will be on the 
table.

Is there any drawback in such step?

Vladimir.



-Joe



___
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] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Tino Heth via swift-evolution]

I think this thread derailed quite a bit — it might have even been a good thing 
that some discussion accidentally went off-list ;-)

Personally, I think it's nice if tuples and structs would converge more, so 
that either struct is seen as an extension of the tuple-concept, or tuple is 
considered to be an (restricted) anonymous struct.
E.g.

struct StructPoint {
let x: Float
let y: Float
}

typealias TuplePoint = (x: Float, y: Float)

would more or less have the same abilities (allowing extensions and 
protocol-conformance).
Constructors for tuples would afaics be easy, and maybe it would even be 
possible to initialize some structs from tuple-literals.

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

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Xiaodi Wu via swift-evolution]

On Tue, Nov 28, 2017 at 00:32 Kelvin Ma  wrote:

> On Mon, Nov 27, 2017 at 9:43 PM, Xiaodi Wu  wrote:
>
>> On Mon, Nov 27, 2017 at 5:56 PM, Kelvin Ma  wrote:
>>
>>>
>>>
>>> On Mon, Nov 27, 2017 at 4:21 PM, Xiaodi Wu  wrote:
>>>
 On Mon, Nov 27, 2017 at 15:46 Taylor Swift 
 wrote:

> they use packed buffers of floats, which for type safety are better
> rebound to a structured type. right now (Float, Float, Float) works 
> because
> the tuple is laid out contiguously and the GPU can’t tell the difference
> but it’s not guaranteed. also you’re ignoring all the CPU stages that 
> occur
> before anything even gets sent to the GPU.
>

 Precisely, there is no guarantee of performance if you call these APIs
 with an array of Swift tuples.

>>>
>>> which is exactly why i support a dedicated language-level vector type
>>> which guarantees contiguous, fixed storage, and which the compiler knows
>>> about so it can vectorize operations on them.
>>>
>>
>> That's an entirely separate discussion.
>>
>>
>>> tuples right now try to fill too many roles and that makes life
>>> difficult for both the compiler and the programmer. however, until then, we
>>> need some kind of common, fixed layout currency type for vector data, and
>>> by implementation-detail, *tuples are our best option* since for some
>>> reason everyone is so opposed to the simple solution of baking vec2,
>>> vec3, … vec5 into the language and the generic integer Vector
>>> solution everyone wants likely isn’t going to materialize for the
>>> foreseeable future.
>>>
>>
>> Disagree. If you want a particular memory layout, define your type in C.
>> Swift's interop story is very good, and your type will have a fixed layout
>> forever.
>>
>
> “*write it in c and import it*” is *not* a solution,, it is a workaround.
>

Yes, that’s what we’re talking about here: workarounds to lack of a fixed
layout type. I’m saying C is the “best option” workaround, not tuples.

plus since it lives across the module boundary, it’s effectively opaque to
> compiler optimizations.
>
What sorts of optimizations are you referring to? Recall that we are
talking about taking a value and unsafe bitcasting for the purposes of
calling other C APIs.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Kelvin Ma via swift-evolution]

On Mon, Nov 27, 2017 at 9:43 PM, Xiaodi Wu  wrote:

> On Mon, Nov 27, 2017 at 5:56 PM, Kelvin Ma  wrote:
>
>>
>>
>> On Mon, Nov 27, 2017 at 4:21 PM, Xiaodi Wu  wrote:
>>
>>> On Mon, Nov 27, 2017 at 15:46 Taylor Swift  wrote:
>>>
 they use packed buffers of floats, which for type safety are better
 rebound to a structured type. right now (Float, Float, Float) works because
 the tuple is laid out contiguously and the GPU can’t tell the difference
 but it’s not guaranteed. also you’re ignoring all the CPU stages that occur
 before anything even gets sent to the GPU.

>>>
>>> Precisely, there is no guarantee of performance if you call these APIs
>>> with an array of Swift tuples.
>>>
>>
>> which is exactly why i support a dedicated language-level vector type
>> which guarantees contiguous, fixed storage, and which the compiler knows
>> about so it can vectorize operations on them.
>>
>
> That's an entirely separate discussion.
>
>
>> tuples right now try to fill too many roles and that makes life difficult
>> for both the compiler and the programmer. however, until then, we need some
>> kind of common, fixed layout currency type for vector data, and by
>> implementation-detail, *tuples are our best option* since for some
>> reason everyone is so opposed to the simple solution of baking vec2, vec3,
>> … vec5 into the language and the generic integer Vector
>> solution everyone wants likely isn’t going to materialize for the
>> foreseeable future.
>>
>
> Disagree. If you want a particular memory layout, define your type in C.
> Swift's interop story is very good, and your type will have a fixed layout
> forever.
>

“*write it in c and import it*” is *not* a solution,, it is a workaround.
plus since it lives across the module boundary, it’s effectively opaque to
compiler optimizations.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Joe Groff via swift-evolution]

> On Nov 20, 2017, at 5:43 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> 
>> On Nov 20, 2017, at 5:39 PM, Kelvin Ma via swift-evolution 
>> > wrote:
>> 
>> when SE-185 
>> 
>>  went through swift evolution, it was agreed that the next logical step 
>>  is 
>> synthesizing these conformances for tuple types, though it was left out of 
>> the original proposal to avoid mission creep. I think now is the time to 
>> start thinking about this. i’m also tacking on Comparable to the other two 
>> protocols because there is precedent in the language from SE-15 
>> 
>>  that tuple comparison is something that makes sense to write.
>> 
>> EHC conformance is even more important for tuples than it is for structs 
>> because tuples effectively have no workaround whereas in structs, you could 
>> just manually implement the conformance. 
> 
> In my opinion, you’re approaching this from the wrong direction.  The 
> fundamental problem here is that tuples can’t conform to a protocol.  If they 
> could, synthesizing these conformances would be straight-forward.

It would be a tractable intermediate problem to introduce built-in conformances 
for tuples (and perhaps metatypes) to Equatable/Hashable/Comparable without 
breaching the more general topic of allowing these types to have general 
protocol conformances. I think that would cover the highest-value use cases.

-Joe

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

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Alejandro Martinez via swift-evolution]

>
> Ah. You seem to be unfamiliar with protocol existentials. Protocols
> (currently, only those without Self or associated type requirements, for
> various implementation reasons) are themselves types. For example, you can
> write:
>

A little offtopic, but I've been wanting to ask if it would be
possible to clarify the definition of existentials on the generics
manifesto (or somewhere than can be easily found by newcomers). I'm
sure I'm not the only one that has a vague notion of what it means but
would still appreciate to have a more concrete definition with some
examples. :D



> ```
> protocol P { }
> extension Int : P { }
> let x: P = 42
> ```
>
> In this example, x is of type `P`, not of type `Int`. Let's clarify the
> difference:
>
> ```
> extension Array where Element == P {
>   func hi() {
> print("Hello")
>   }
> }
>
> extension Array where Element : P {
>   func hi() {
> print("World!")
>   }
> }
>
> let y: [P] = [x]
> let z: [Int] = [x as Int]
>
> y.hi() // Prints "Hello"
> z.hi() // Prints "World!"
> ```
>
> Moreover, if we do not write the first `extension Array`, then `y.hi()`
> doesn't compile. This helps to illustrate that P does not conform to itself.
>
>
>>> For a type T : P, a tuple of type (T, T) is not a tuple of type (P, P).
>>> If we can extend tuples, you can write a generic algorithm that works with
>>> any type (T, T) where T : P, and/or you can write an algorithm that works
>>> with concrete type (P, P). Note that there is no overlap between these two
>>> because existential type P does not conform to protocol P.
>>>
>>
>> Mike
>>
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>



-- 
Alejandro Martinez
http://alejandromp.com
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Tino Heth via swift-evolution]

> Why do you need to have this ability to unsafe bitcast? Is interconversion 
> between point types such a common operation that it's a performance 
> bottleneck?
A real-world example: Real-time image processing.
When you have a stream of 4k pictures at 30 fps, you really don’t wont to copy 
buffers just because two filters insist on having their own representation of 
bitmap data.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Tino Heth via swift-evolution]

> ps i remember that pitch because i’m pretty sure i was the one that pitched 
> that.
No, I was writing about that one: 
https://www.mail-archive.com/swift-evolution@swift.org/msg30565.html

> consensus seemed it was too high level for inclusion (even though having it 
> at the stdlib level would do wonders for things like SIMD) and everyone got 
> distracted by “integers as generic parameters” (because we love `Vector<3>` 
> ig) because everything on this list always devolves into “but this is really 
> a problem with the generics system” and since no one knows how to fix the 
> generics system everyone calls it a day and forgets about the original issue

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

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[John McCall via swift-evolution]

> On Nov 27, 2017, at 1:43 AM, David Hart  wrote:
> On 27 Nov 2017, at 07:32, John McCall  > wrote:
> 
>> 
>>> On Nov 22, 2017, at 2:01 AM, David Hart via swift-evolution 
>>> > wrote:
>>> 
>>> 
>>> 
 On 22 Nov 2017, at 07:48, David Hart via swift-evolution 
 > wrote:
 
 
 
 On 22 Nov 2017, at 07:41, Douglas Gregor via swift-evolution 
 > wrote:
 
> 
> 
>> On Nov 21, 2017, at 10:37 PM, Chris Lattner > > wrote:
>> 
>> On Nov 21, 2017, at 9:25 PM, Douglas Gregor > > wrote:
 Or alternatively, one could decide to make the generics system *only 
 and forever* work on nominal types, and make the syntactic sugar just 
 be sugar for named types like Swift.Tuple, Function, and Optional.  
 Either design could work.
>>> 
>>> We don’t have a way to make it work for function types, though, because 
>>> of parameter-passing conventions. Well, assuming we don’t invent 
>>> something that allows:
>>> 
>>> Function
>>> 
>>> to exist in the type system. Tuple labels have a similar problem.
>> 
>> I’m totally aware of that and mentioned it upthread.
> 
> Eh, sorry I missed it.
> 
>>  There are various encoding tricks that could make this work depending 
>> on how you want to stretch the current generics system…
> 
> I think it’s straightforward and less ugly to make structural types allow 
> extensions and protocol conformances.
 
 Can somebody explain to me what is less ugly about that? I would have 
 naturally thought that the language would be simpler as a whole if there 
 only existed nominal types and all structural types were just sugar over 
 them.
>>> 
>>> What confuses me is that I always thought that T? was sugar for Optional 
>>> by design, and found that to be quite elegant. But now you’re telling me 
>>> that its just a hack to allow conformance on Optionals until it can be made 
>>> structural. I would have thought that it would be cleaner to have specific 
>>> concepts (optionals, tuples, etc…) represented in terms of more general 
>>> concepts (enum, struct) so that the compiler had less to reason about. I’m 
>>> just trying to understand :-)
>> 
>> Don't worry too much about it.  The people in this thread are conflating a 
>> lot of different things, including some people who ought to know better.  
>> Your way of looking at it is perfectly accurate.
>> 
>> A fairly standard formalization of types is that you have these type 
>> expressions, which, in a simple system, are either type constants or type 
>> applications.
>> 
>> A type constant is something like Int, Float, or Array.  struct/enum/class 
>> declarations in Swift all introduce new type constants, where each 
>> declaration has its own identity as a type.  Since we don't allow type names 
>> to be redeclared in a scope, the identity of such declared types can be 
>> uniquely determined by (1) the type's name in its scope and (2) the path to 
>> that scope.  Hence the identity is "by name", or "nominal".
>> 
>> A type application takes a generic type and applies it at some number of 
>> arguments.  The general syntax for this in Swift is <>.  For example, Array 
>> is a generic type, and Array is a type application of the generic type 
>> Array with the argument Int.  The arguments can be arbitrary type 
>> expressions, e.g. Dictionary.  The identity of a type 
>> application is determined purely by its applicative structure: first, the 
>> identity of the generic type being applied, and second, the identity of the 
>> type arguments it is being applied to.  That is, A is the same type as 
>> C as long as the type-expression A is the same generic type as C and B is 
>> the same type as D.  Hence the identity is "structural".
>> 
>> (Formal nitpick: we're making some assumptions about the nature of type 
>> expressions that generally work out until you get into really advanced type 
>> systems.)
>> 
>> What is a tuple type in this formalization?  Well, the rule we want is that 
>> (A, B) is the same type as (C, D) if A is identical to C and B is identical 
>> to D.  We could add this as a special new rule to our definition of type 
>> expressions above, but we don't really need to, because it turns out that 
>> it's exactly the same as if we had some sort of tuple type constant — for 
>> sake of argument, let's call it (...) — and allowed it to be applied to an 
>> arbitrary number of types.  Swift does not actually allow you to name this 
>> as an unapplied generic type — you 

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[David Hart via swift-evolution]

> On 27 Nov 2017, at 07:32, John McCall  wrote:
> 
> 
>>> On Nov 22, 2017, at 2:01 AM, David Hart via swift-evolution 
>>>  wrote:
>>> 
>>> 
>>> 
>>> On 22 Nov 2017, at 07:48, David Hart via swift-evolution 
>>>  wrote:
>>> 
>>> 
>>> 
>>> On 22 Nov 2017, at 07:41, Douglas Gregor via swift-evolution 
>>>  wrote:
>>> 
 
 
> On Nov 21, 2017, at 10:37 PM, Chris Lattner  wrote:
> 
> On Nov 21, 2017, at 9:25 PM, Douglas Gregor  wrote:
>>> Or alternatively, one could decide to make the generics system *only 
>>> and forever* work on nominal types, and make the syntactic sugar just 
>>> be sugar for named types like Swift.Tuple, Function, and Optional.  
>>> Either design could work.
>> 
>> We don’t have a way to make it work for function types, though, because 
>> of parameter-passing conventions. Well, assuming we don’t invent 
>> something that allows:
>> 
>>  Function
>> 
>> to exist in the type system. Tuple labels have a similar problem.
> 
> I’m totally aware of that and mentioned it upthread.
 
 Eh, sorry I missed it.
 
>  There are various encoding tricks that could make this work depending on 
> how you want to stretch the current generics system…
 
 I think it’s straightforward and less ugly to make structural types allow 
 extensions and protocol conformances.
>>> 
>>> Can somebody explain to me what is less ugly about that? I would have 
>>> naturally thought that the language would be simpler as a whole if there 
>>> only existed nominal types and all structural types were just sugar over 
>>> them.
>> 
>> What confuses me is that I always thought that T? was sugar for Optional 
>> by design, and found that to be quite elegant. But now you’re telling me 
>> that its just a hack to allow conformance on Optionals until it can be made 
>> structural. I would have thought that it would be cleaner to have specific 
>> concepts (optionals, tuples, etc…) represented in terms of more general 
>> concepts (enum, struct) so that the compiler had less to reason about. I’m 
>> just trying to understand :-)
> 
> Don't worry too much about it.  The people in this thread are conflating a 
> lot of different things, including some people who ought to know better.  
> Your way of looking at it is perfectly accurate.
> 
> A fairly standard formalization of types is that you have these type 
> expressions, which, in a simple system, are either type constants or type 
> applications.
> 
> A type constant is something like Int, Float, or Array.  struct/enum/class 
> declarations in Swift all introduce new type constants, where each 
> declaration has its own identity as a type.  Since we don't allow type names 
> to be redeclared in a scope, the identity of such declared types can be 
> uniquely determined by (1) the type's name in its scope and (2) the path to 
> that scope.  Hence the identity is "by name", or "nominal".
> 
> A type application takes a generic type and applies it at some number of 
> arguments.  The general syntax for this in Swift is <>.  For example, Array 
> is a generic type, and Array is a type application of the generic type 
> Array with the argument Int.  The arguments can be arbitrary type 
> expressions, e.g. Dictionary.  The identity of a type 
> application is determined purely by its applicative structure: first, the 
> identity of the generic type being applied, and second, the identity of the 
> type arguments it is being applied to.  That is, A is the same type as 
> C as long as the type-expression A is the same generic type as C and B is 
> the same type as D.  Hence the identity is "structural".
> 
> (Formal nitpick: we're making some assumptions about the nature of type 
> expressions that generally work out until you get into really advanced type 
> systems.)
> 
> What is a tuple type in this formalization?  Well, the rule we want is that 
> (A, B) is the same type as (C, D) if A is identical to C and B is identical 
> to D.  We could add this as a special new rule to our definition of type 
> expressions above, but we don't really need to, because it turns out that 
> it's exactly the same as if we had some sort of tuple type constant — for 
> sake of argument, let's call it (...) — and allowed it to be applied to an 
> arbitrary number of types.  Swift does not actually allow you to name this as 
> an unapplied generic type — you cannot write (...) instead of 
> (Int, Float) — but that's just a matter of syntax.  The fact that (...) is 
> built into the language rather than being declared in the standard library as 
> Tuple is not fundamentally significant.  Nor is it fundamentally significant 
> for Optional, which is currently declared in the standard library instead of 
> being 

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[John McCall via swift-evolution]

> On Nov 22, 2017, at 2:01 AM, David Hart via swift-evolution 
>  wrote:
> 
> 
> 
>> On 22 Nov 2017, at 07:48, David Hart via swift-evolution 
>> > wrote:
>> 
>> 
>> 
>> On 22 Nov 2017, at 07:41, Douglas Gregor via swift-evolution 
>> > wrote:
>> 
>>> 
>>> 
 On Nov 21, 2017, at 10:37 PM, Chris Lattner > wrote:
 
 On Nov 21, 2017, at 9:25 PM, Douglas Gregor > wrote:
>> Or alternatively, one could decide to make the generics system *only and 
>> forever* work on nominal types, and make the syntactic sugar just be 
>> sugar for named types like Swift.Tuple, Function, and Optional.  Either 
>> design could work.
> 
> We don’t have a way to make it work for function types, though, because 
> of parameter-passing conventions. Well, assuming we don’t invent 
> something that allows:
> 
>   Function
> 
> to exist in the type system. Tuple labels have a similar problem.
 
 I’m totally aware of that and mentioned it upthread.
>>> 
>>> Eh, sorry I missed it.
>>> 
  There are various encoding tricks that could make this work depending on 
 how you want to stretch the current generics system…
>>> 
>>> I think it’s straightforward and less ugly to make structural types allow 
>>> extensions and protocol conformances.
>> 
>> Can somebody explain to me what is less ugly about that? I would have 
>> naturally thought that the language would be simpler as a whole if there 
>> only existed nominal types and all structural types were just sugar over 
>> them.
> 
> What confuses me is that I always thought that T? was sugar for Optional 
> by design, and found that to be quite elegant. But now you’re telling me that 
> its just a hack to allow conformance on Optionals until it can be made 
> structural. I would have thought that it would be cleaner to have specific 
> concepts (optionals, tuples, etc…) represented in terms of more general 
> concepts (enum, struct) so that the compiler had less to reason about. I’m 
> just trying to understand :-)

Don't worry too much about it.  The people in this thread are conflating a lot 
of different things, including some people who ought to know better.  Your way 
of looking at it is perfectly accurate.

A fairly standard formalization of types is that you have these type 
expressions, which, in a simple system, are either type constants or type 
applications.

A type constant is something like Int, Float, or Array.  struct/enum/class 
declarations in Swift all introduce new type constants, where each declaration 
has its own identity as a type.  Since we don't allow type names to be 
redeclared in a scope, the identity of such declared types can be uniquely 
determined by (1) the type's name in its scope and (2) the path to that scope.  
Hence the identity is "by name", or "nominal".

A type application takes a generic type and applies it at some number of 
arguments.  The general syntax for this in Swift is <>.  For example, Array is 
a generic type, and Array is a type application of the generic type Array 
with the argument Int.  The arguments can be arbitrary type expressions, e.g. 
Dictionary.  The identity of a type application is 
determined purely by its applicative structure: first, the identity of the 
generic type being applied, and second, the identity of the type arguments it 
is being applied to.  That is, A is the same type as C as long as the 
type-expression A is the same generic type as C and B is the same type as D.  
Hence the identity is "structural".

(Formal nitpick: we're making some assumptions about the nature of type 
expressions that generally work out until you get into really advanced type 
systems.)

What is a tuple type in this formalization?  Well, the rule we want is that (A, 
B) is the same type as (C, D) if A is identical to C and B is identical to D.  
We could add this as a special new rule to our definition of type expressions 
above, but we don't really need to, because it turns out that it's exactly the 
same as if we had some sort of tuple type constant — for sake of argument, 
let's call it (...) — and allowed it to be applied to an arbitrary number of 
types.  Swift does not actually allow you to name this as an unapplied generic 
type — you cannot write (...) instead of (Int, Float) — but that's 
just a matter of syntax.  The fact that (...) is built into the language rather 
than being declared in the standard library as Tuple is not fundamentally 
significant.  Nor is it fundamentally significant for Optional, which is 
currently declared in the standard library instead of being built-in.

(Function types in Swift are weird because, as covered previously in this 

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Mike Kluev via swift-evolution]

On 25 November 2017 at 23:39, Xiaodi Wu  wrote:

> On Sat, Nov 25, 2017 at 5:21 PM, Mike Kluev  wrote:
>
>> On 25 November 2017 at 23:07, Xiaodi Wu  wrote:
>>
>>> Not sure what you’re asking. Equatable is a protocol.
>>>
>>
>> that's the point. i mean, if user writes this:
>>
>> extension (Equatable, Equatable) : Equatable
>>
>> what *else* could he mean other than this:
>>
>> extension  (T, R) : Equatable
>>
>
> No, it would mean extending the concrete type `(Equatable, Equatable)`
> (which has other roadblocks to becoming possible because Equatable has Self
> requirements).
>

>
>> and if it is indeed the only reasonable meaning we can think of - i'd say
>> the first notation is nicer.
>>
>>
>>> For a protocol P, (P, P) is a concrete type with two elements each of
>>> existential type P.
>>>
>>
>> this part i do not understand. protocol is not an existential type. or is
>> it?
>>
>
> Ah. You seem to be unfamiliar with protocol existentials. Protocols
> (currently, only those without Self or associated type requirements, for
> various implementation reasons) are themselves types. For example, you can
> write:
>
> ```
> protocol P { }
> extension Int : P { }
> let x: P = 42
> ```
>

thanks, indeed i was totally unaware of this. can't even find it in the
language reference.

if i decipher this correctly, the above example with Equatable is probably
"fine" (because Equatable has self requirement) but in other cases it won't
be fine.


> In this example, x is of type `P`, not of type `Int`. Let's clarify the
> difference:
>
> ```
> extension Array where Element == P {
>   func hi() {
> print("Hello")
>   }
> }
>
> extension Array where Element : P {
>   func hi() {
> print("World!")
>   }
> }
>
> let y: [P] = [x]
> let z: [Int] = [x as Int]
>
> y.hi() // Prints "Hello"
> z.hi() // Prints "World!"
> ```
>
> Moreover, if we do not write the first `extension Array`, then `y.hi()`
> doesn't compile. This helps to illustrate that P does not conform to itself.
>


thanks for example. too subtle feature imho. i never thought protocol could
be a type on it's own, makes the whole story more complex.

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

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Xiaodi Wu via swift-evolution]

On Sat, Nov 25, 2017 at 5:21 PM, Mike Kluev  wrote:

> On 25 November 2017 at 23:07, Xiaodi Wu  wrote:
>
>> Not sure what you’re asking. Equatable is a protocol.
>>
>
> that's the point. i mean, if user writes this:
>
> extension (Equatable, Equatable) : Equatable
>
> what *else* could he mean other than this:
>
> extension  (T, R) : Equatable
>

No, it would mean extending the concrete type `(Equatable, Equatable)`
(which has other roadblocks to becoming possible because Equatable has Self
requirements).


> and if it is indeed the only reasonable meaning we can think of - i'd say
> the first notation is nicer.
>
>
>> For a protocol P, (P, P) is a concrete type with two elements each of
>> existential type P.
>>
>
> this part i do not understand. protocol is not an existential type. or is
> it?
>

Ah. You seem to be unfamiliar with protocol existentials. Protocols
(currently, only those without Self or associated type requirements, for
various implementation reasons) are themselves types. For example, you can
write:

```
protocol P { }
extension Int : P { }
let x: P = 42
```

In this example, x is of type `P`, not of type `Int`. Let's clarify the
difference:

```
extension Array where Element == P {
  func hi() {
print("Hello")
  }
}

extension Array where Element : P {
  func hi() {
print("World!")
  }
}

let y: [P] = [x]
let z: [Int] = [x as Int]

y.hi() // Prints "Hello"
z.hi() // Prints "World!"
```

Moreover, if we do not write the first `extension Array`, then `y.hi()`
doesn't compile. This helps to illustrate that P does not conform to itself.


For a type T : P, a tuple of type (T, T) is not a tuple of type (P, P). If
>> we can extend tuples, you can write a generic algorithm that works with any
>> type (T, T) where T : P, and/or you can write an algorithm that works with
>> concrete type (P, P). Note that there is no overlap between these two
>> because existential type P does not conform to protocol P.
>>
>>
> Mike
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Mike Kluev via swift-evolution]

on Date: Wed, 22 Nov 2017 08:01:16 +0100 David Hart 
wrote:

>
> What confuses me is that I always thought that T? was sugar for
> Optional by design, and found that to be quite elegant.


ditto, i thought the same.


> But now you’re telling me that its just a hack to allow conformance on
> Optionals until it can be made structural. I would have thought that it
> would be cleaner to have specific concepts (optionals, tuples, etc…)
> represented in terms of more general concepts (enum, struct) so that the
> compiler had less to reason about. I’m just trying to understand :-)
>

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

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Mike Kluev via swift-evolution]

On 25 November 2017 at 23:07, Xiaodi Wu  wrote:

> Not sure what you’re asking. Equatable is a protocol.
>

that's the point. i mean, if user writes this:

extension (Equatable, Equatable) : Equatable

what *else* could he mean other than this:

extension  (T, R) : Equatable

and if it is indeed the only reasonable meaning we can think of - i'd say
the first notation is nicer.


> For a protocol P, (P, P) is a concrete type with two elements each of
> existential type P.
>

this part i do not understand. protocol is not an existential type. or is
it?


> For a type T : P, a tuple of type (T, T) is not a tuple of type (P, P). If
> we can extend tuples, you can write a generic algorithm that works with any
> type (T, T) where T : P, and/or you can write an algorithm that works with
> concrete type (P, P). Note that there is no overlap between these two
> because existential type P does not conform to protocol P.
>
>
Mike
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Xiaodi Wu via swift-evolution]

On Sat, Nov 25, 2017 at 16:44 Mike Kluev  wrote:

> On 25 November 2017 at 22:38, Xiaodi Wu  wrote:
>
>> On Sat, Nov 25, 2017 at 4:30 PM, Mike Kluev  wrote:
>>
>>>
 i haven't encounter this notation before so it looks strange and
>>> requires some effort to decipher. if it was e.g. in this form:
>>>
>>> extension (Equatable...) : Equatable
>>>
>>> then it would be immediately obvious what it means, IMHO
>>>
>>
>> That reads to me like you are extending a tuple of type `(Equatable...)`.
>> This is not the same as extending a tuple of type `(E...) where ...E :
>> Equatable`.
>>
>
> and if Equatable is not a type but a protocol then the practical
> difference is what ?
>

Not sure what you’re asking. Equatable is a protocol.

For a protocol P, (P, P) is a concrete type with two elements each of
existential type P. For a type T : P, a tuple of type (T, T) is not a tuple
of type (P, P). If we can extend tuples, you can write a generic algorithm
that works with any type (T, T) where T : P, and/or you can write an
algorithm that works with concrete type (P, P). Note that there is no
overlap between these two because existential type P does not conform to
protocol P.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Mike Kluev via swift-evolution]

on Date: Thu, 23 Nov 2017 09:56:35 +1100 Howard Lovatt <
howard.lov...@gmail.com> wrote:

>
> I would defend turning tuples into structs (change from structural type to
> nominal type). This is a much better story for programmers, compare the two
> stories:
>
>1. Tuples are just syntax sugar for simple structs.
>2. Tuples are sort of like structs but there is a list of things tuples
>can do that structs can't and a list of things structs can do and tuples
>can't.
>
> I think unification can be achieved with some name mangling (Chris Lattner
> noted this previously - I am just spelling out one scheme), e.g.:
>
> // var a = (zero: 0, one: 1)
> public struct Tuple_zero_Int_one_Int { // Mangle name.
> public var zero: Int
> public var one: Int
> }
> var a = Tuple_zero_Int_one_Int(zero: 0, one: 1)
> // a.0 = -1
> a.zero = -1
>
> // var b = (0, 1)
> public struct Tuple_0_Int_1_Int { // Mangle name.
> public var _0_: Int // Unique name.
> public var _1_: Int // Unique name.
> }
> var b = Tuple_0_Int_1_Int(_0_: 0, _1_: 1)
> // a = b
> a = Tuple_zero_Int_one_Int(zero: b._0_, one: b._1_)
>
>
> Implicit in the above transformation is:
>
>1. struct and tuple have the same memory layout.
>2. `.0` access the 1st stored property of a struct, `.1` the 2nd, etc.
>

not sure about the name mangling per se, but the very idea of treating
tuples as structs is awesome and worth exploring.

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

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Mike Kluev via swift-evolution]

On 25 November 2017 at 22:38, Xiaodi Wu  wrote:

> On Sat, Nov 25, 2017 at 4:30 PM, Mike Kluev  wrote:
>
>>
>>> i haven't encounter this notation before so it looks strange and
>> requires some effort to decipher. if it was e.g. in this form:
>>
>> extension (Equatable...) : Equatable
>>
>> then it would be immediately obvious what it means, IMHO
>>
>
> That reads to me like you are extending a tuple of type `(Equatable...)`.
> This is not the same as extending a tuple of type `(E...) where ...E :
> Equatable`.
>

and if Equatable is not a type but a protocol then the practical difference
is what ?

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

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Xiaodi Wu via swift-evolution]

On Sat, Nov 25, 2017 at 4:30 PM, Mike Kluev  wrote:

> On 25 November 2017 at 16:04, Xiaodi Wu  wrote:
>
>>
>> The workaround substantially bloats the standard library, and the result
>> is nothing close to the same because your type is still not Equatable. This
>> means that it cannot benefit from any generic algorithms. For example, an
>> array of such tuples cannot be Equatable in turn.
>>
>>>
>>
> i see. then the current workaround is not deep enough.
>
>
>> speaking of ugliness, the ellipsis on the left of names is quite ugly:
>>>
>>>  extension<...Elements : Equatable> (Elements...) : Equatable
>>>
>>
>> Seems perfectly fine to me.
>>
>
> i haven't encounter this notation before so it looks strange and requires
> some effort to decipher. if it was e.g. in this form:
>
> extension (Equatable...) : Equatable
>
> then it would be immediately obvious what it means, IMHO
>

That reads to me like you are extending a tuple of type `(Equatable...)`.
This is not the same as extending a tuple of type `(E...) where ...E :
Equatable`.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Mike Kluev via swift-evolution]

On 25 November 2017 at 16:04, Xiaodi Wu  wrote:

>
> The workaround substantially bloats the standard library, and the result
> is nothing close to the same because your type is still not Equatable. This
> means that it cannot benefit from any generic algorithms. For example, an
> array of such tuples cannot be Equatable in turn.
>
>>
>
i see. then the current workaround is not deep enough.


> speaking of ugliness, the ellipsis on the left of names is quite ugly:
>>
>>  extension<...Elements : Equatable> (Elements...) : Equatable
>>
>
> Seems perfectly fine to me.
>

i haven't encounter this notation before so it looks strange and requires
some effort to decipher. if it was e.g. in this form:

extension (Equatable...) : Equatable

then it would be immediately obvious what it means, IMHO

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

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[David Sweeris via swift-evolution]

> On Nov 25, 2017, at 08:05, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> 
>> On Sat, Nov 25, 2017 at 06:35 Mike Kluev  wrote:
>>> On 25 November 2017 at 03:12, Xiaodi Wu  wrote:
>> 
 On Fri, Nov 24, 2017 at 9:08 PM, Mike Kluev via swift-evolution 
  wrote:
>>> 
> On 24 November 2017 at 23:47, Douglas Gregor  wrote:
 
> 
> e.g., making all tuples of Equatable elements Equatable 
 
 that's already the case.. (all tuples of equatable elements are 
 equatable). no?
>>> 
>>> No, tuples do not conform to any protocols. There are hardcoded 
>>> implementations of `==` up to some arity in the stdlib to partially 
>>> mitigate the lack of protocol conformance.
>> 
>> to me as a user the end result is the same...
>> probably we need a better convincing example of what users may want that 
>> doesn't have a workaround now.
> 
> The workaround substantially bloats the standard library, and the result is 
> nothing close to the same because your type is still not Equatable. This 
> means that it cannot benefit from any generic algorithms. For example, an 
> array of such tuples cannot be Equatable in turn.
> 
>> speaking of ugliness, the ellipsis on the left of names is quite ugly:
>> 
>>  extension<...Elements : Equatable> (Elements...) : Equatable
> 
> Seems perfectly fine to me.

Agreed.

Speaking of which, have we started designing the syntax & semantics of the 
variadic generics/tuples system yet? I’ve been away from my computer a lot 
lately, and I tend to miss threads when subject lines gets truncated to 
“[swift-evolution][pitch] Some subj” on my phone.

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

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Xiaodi Wu via swift-evolution]

On Sat, Nov 25, 2017 at 06:35 Mike Kluev  wrote:

> On 25 November 2017 at 03:12, Xiaodi Wu  wrote:
>
>> On Fri, Nov 24, 2017 at 9:08 PM, Mike Kluev via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> On 24 November 2017 at 23:47, Douglas Gregor  wrote:
>>>

 e.g., making all tuples of Equatable elements Equatable


>>> that's already the case.. (all tuples of equatable elements are
>>> equatable). no?
>>>
>>
>> No, tuples do not conform to any protocols. There are hardcoded
>> implementations of `==` up to some arity in the stdlib to partially
>> mitigate the lack of protocol conformance.
>>
>>
> to me as a user the end result is the same...
> probably we need a better convincing example of what users may want that
> doesn't have a workaround now.
>

The workaround substantially bloats the standard library, and the result is
nothing close to the same because your type is still not Equatable. This
means that it cannot benefit from any generic algorithms. For example, an
array of such tuples cannot be Equatable in turn.

>
speaking of ugliness, the ellipsis on the left of names is quite ugly:
>
>  extension<...Elements : Equatable> (Elements...) : Equatable
>

Seems perfectly fine to me.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Mike Kluev via swift-evolution]

On 25 November 2017 at 03:12, Xiaodi Wu  wrote:

> On Fri, Nov 24, 2017 at 9:08 PM, Mike Kluev via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> On 24 November 2017 at 23:47, Douglas Gregor  wrote:
>>
>>>
>>> e.g., making all tuples of Equatable elements Equatable
>>>
>>>
>> that's already the case.. (all tuples of equatable elements are
>> equatable). no?
>>
>
> No, tuples do not conform to any protocols. There are hardcoded
> implementations of `==` up to some arity in the stdlib to partially
> mitigate the lack of protocol conformance.
>
>
to me as a user the end result is the same...
probably we need a better convincing example of what users may want that
doesn't have a workaround now.

speaking of ugliness, the ellipsis on the left of names is quite ugly:

 extension<...Elements : Equatable> (Elements...) : Equatable

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

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Chris Lattner via swift-evolution]

On Nov 24, 2017, at 9:20 PM, Douglas Gregor  wrote:
>> Ok, so you just happened to pick a simple one:
> 
> Yup. Try to make a nominal type to describe labeled tuples.

People keep talking about adding integer values to generics, why not strings 
too? ;-)

>> what is the benefit of plumbing knowledge of metatypes through the entire 
>> generics system,
> 
> That’s not how one would implement this in the compiler. Most of the compiler 
> doesn’t care whether the subject of a protocol conformance is a nominal type 
> or not, and those scattered (but numerous) places that do care should be 
> straightforward to generalize to include structural types. It’s not 
> metatype-specific work.

Sure, I can buy that.  The thing that you’re leaving out is that you have to 
also generalize those (numerous) places to handle all the complexities of those 
non-nominal types.  The system has to handle keywords, inout arguments, etc 
somehow, and therefore the complexity to handle them needs to go somewhere.

The question is only whether one design or the other produces a lower energy 
state of complexity.  Given that I don’t know this code at all, if you think 
that your way is the best way to model it, then I’ll happily believe you. :-)

-Chris

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

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Douglas Gregor via swift-evolution]

Sent from my iPhone

> On Nov 24, 2017, at 4:06 PM, Chris Lattner  wrote:
> 
>> On Nov 24, 2017, at 3:47 PM, Douglas Gregor via swift-evolution 
>>  wrote:
>> One could imagine adding a “curry” operation to function types:
> 
> Right, having non-nominal types participate in the generics system would be 
> undoubtably awesome! :)
> 
>> Or perhaps making metatypes Hashable so they can be used as keys into a 
>> Dictionary:
>> 
>>  extension T.Type: Hashable {
> 
> Ok, so you just happened to pick a simple one:

Yup. Try to make a nominal type to describe labeled tuples. 

> what is the benefit of plumbing knowledge of metatypes through the entire 
> generics system,

That’s not how one would implement this in the compiler. Most of the compiler 
doesn’t care whether the subject of a protocol conformance is a nominal type or 
not, and those scattered (but numerous) places that do care should be 
straightforward to generalize to include structural types. It’s not 
metatype-specific work.

> rather than define a “Swift.Metatype” type, and defining stuff against it?

It would be a nominal type in name only (pun intended!), with special cases 
throughout the compiler and ABI—like we have with Optional, except with poorer 
test coverage. Worse, unlike the generalization I discuss above, where one 
generalization refactoring makes all structural types work, we’d have to  put 
in all of the not-really-nominal hacks for each currently-structural type on a 
case-by-case basis. 

  - Doug

> 
> -Chris
> 
> 
> 
>>var hashValue: Int {
>>  return ObjectIdentifier(self).hashValue
>>}
>> 
>>   static func ==(lhs: T.Type, rhs: T.Type) -> Bool { /* standard library 
>> magic */ }
>>  }
>> 
>>- Doug
>> 
>> 
>> ___
>> 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] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Xiaodi Wu via swift-evolution]

On Fri, Nov 24, 2017 at 9:08 PM, Mike Kluev via swift-evolution <
swift-evolution@swift.org> wrote:

> On 24 November 2017 at 23:47, Douglas Gregor  wrote:
>
>>
>> e.g., making all tuples of Equatable elements Equatable
>>
>>
> that's already the case.. (all tuples of equatable elements are
> equatable). no?
>

No, tuples do not conform to any protocols. There are hardcoded
implementations of `==` up to some arity in the stdlib to partially
mitigate the lack of protocol conformance.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Mike Kluev via swift-evolution]

On 24 November 2017 at 23:47, Douglas Gregor  wrote:

>
> e.g., making all tuples of Equatable elements Equatable
>
>
that's already the case.. (all tuples of equatable elements are equatable).
no?

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

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Chris Lattner via swift-evolution]

On Nov 24, 2017, at 3:47 PM, Douglas Gregor via swift-evolution 
 wrote:
> One could imagine adding a “curry” operation to function types:

Right, having non-nominal types participate in the generics system would be 
undoubtably awesome! :)

> Or perhaps making metatypes Hashable so they can be used as keys into a 
> Dictionary:
> 
>   extension T.Type: Hashable {

Ok, so you just happened to pick a simple one: what is the benefit of plumbing 
knowledge of metatypes through the entire generics system, rather than define a 
“Swift.Metatype” type, and defining stuff against it?

-Chris



> var hashValue: Int {
>   return ObjectIdentifier(self).hashValue
> }
> 
>static func ==(lhs: T.Type, rhs: T.Type) -> Bool { /* standard library 
> magic */ }
>   }
> 
>   - Doug
> 
> 
> ___
> 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] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Douglas Gregor via swift-evolution]

> On Nov 22, 2017, at 2:59 PM, Mike Kluev  wrote:
> 
> on Date: Tue, 21 Nov 2017 22:54:21 -0800 Douglas Gregor  > wrote:
> 
> > On Nov 21, 2017, at 10:48 PM, David Hart  > > wrote:
> >
> > On 22 Nov 2017, at 07:41, Douglas Gregor via swift-evolution 
> >  
> > >> 
> > wrote:
> >
> >>
> >> I think it’s straightforward and less ugly to make structural types allow 
> >> extensions and protocol conformances.
> >
> > Can somebody explain to me what is less ugly about that? I would have 
> > naturally thought that the language would be simpler as a whole if there 
> > only existed nominal types and all structural types were just sugar over 
> > them.
> 
> See Thorsten’s response with, e.g.,
> 
>   Function
> 
> which handles “inout” by adding wrappers around the parameter types (which 
> one would have to cope with in any user of Function), but still doesn’t 
> handle argument labels. To handle argument labels, we would need something 
> like strings as generic arguments. We’d also need to handle calling 
> conventions and anything else we invent for function types.
> 
> 
> can you outline how extensions and protocol conformances might look for 
> structural types? to compare the ugliness of both approaches.

There are some examples at


https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#extensions-of-structural-types

e.g., making all tuples of Equatable elements Equatable (which also mixes in 
conditional conformances and variadic generics):

extension<...Elements : Equatable> (Elements...) : Equatable { // 
extending the tuple type "(Elements...)" to be Equatable
}

One could imagine adding a “curry” operation to function types:

  extension (Param1, Param2) -> Result {
var curried: (Param1) -> (Param2) -> Result {
  return { (arg1: Param1) in { (arg2: Param2) in self(arg1, arg2) } }
}
  }

Or perhaps making metatypes Hashable so they can be used as keys into a 
Dictionary:

  extension T.Type: Hashable {
var hashValue: Int {
  return ObjectIdentifier(self).hashValue
}

   static func ==(lhs: T.Type, rhs: T.Type) -> Bool { /* standard library magic 
*/ }
  }

- Doug


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

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Xiaodi Wu via swift-evolution]

On Thu, Nov 23, 2017 at 6:27 PM, Kelvin Ma  wrote:

>
>
> On Thu, Nov 23, 2017 at 7:08 PM, Xiaodi Wu  wrote:
>
>>
>> On Thu, Nov 23, 2017 at 16:45 Kelvin Ma via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>>
>>>
>>> On Thu, Nov 23, 2017 at 12:32 PM, Tino Heth <2...@gmx.de> wrote:
>>>

 a good idea on paper, a disastrous one in practice. What happens if
 every geometry library declares their own Point type?

 That would be ugly („disastrous“ imho is a little bit to strong — C++
 had/has similar issues, and other languages as well)
 But if there would be a simple Point struct in a library that is
 popular (could be achieved by shipping it alongside the stdlib), this
 problem would be solved (there has been a pitch lately, but I guess it
 faded away silently).

>>>
>>> it’s ugly in C++ and disastrous in Swift because C++ has fixed layout
>>> guarantees and everyone agrees that z comes after y comes after x, so you
>>> can unsafe-bitcast the foreign C++ points into your own points “for free”.
>>> you can’t do the same thing in Swift
>>>
>>
>> Why do you need to have this ability to unsafe bitcast? Is
>> interconversion between point types such a common operation that it's a
>> performance bottleneck?
>>
>
> idk if it’s a performance bottleneck because i use tuples in my geometry
> stack and i keep the bottom 2 levels in the same module but it cannot be
> good. a lot of the geometry code I write sits atop 2 or 3 other layers of
> geometry code beneath it, and it interops with geometry APIs in other
> libraries. for example it might be organized like
>
> [ Client geometry code ] ←→ [ Library geometry code ] (example:
> Voronoi.voronoi(_:), Noise.perlin(_:_:))
>[ Procedurally generated geometry ] (example:
> makeSphere(resolution:))
>[Matrices and projections ] (example:
> Geometry.clockwise(_:_:center:normal:))
>[   Math  ] (example: Math.cross(_:_:))
>
> converting at every boundary seems like something to avoid. not to mention
> the sheer amount of boilerplate all those conversions produce.
>

FWIW, tuples are only guaranteed to have a C-compatible layout when exposed
to C; that is, Swift doesn't guarantee that there will not be optimizations
in the future that change tuple layout such that a call into C will cause
your tuples to do interop gymnastics.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Kelvin Ma via swift-evolution]

On Thu, Nov 23, 2017 at 7:08 PM, Xiaodi Wu  wrote:

>
> On Thu, Nov 23, 2017 at 16:45 Kelvin Ma via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>>
>> On Thu, Nov 23, 2017 at 12:32 PM, Tino Heth <2...@gmx.de> wrote:
>>
>>>
>>> a good idea on paper, a disastrous one in practice. What happens if
>>> every geometry library declares their own Point type?
>>>
>>> That would be ugly („disastrous“ imho is a little bit to strong — C++
>>> had/has similar issues, and other languages as well)
>>> But if there would be a simple Point struct in a library that is popular
>>> (could be achieved by shipping it alongside the stdlib), this problem would
>>> be solved (there has been a pitch lately, but I guess it faded away
>>> silently).
>>>
>>
>> it’s ugly in C++ and disastrous in Swift because C++ has fixed layout
>> guarantees and everyone agrees that z comes after y comes after x, so you
>> can unsafe-bitcast the foreign C++ points into your own points “for free”.
>> you can’t do the same thing in Swift
>>
>
> Why do you need to have this ability to unsafe bitcast? Is interconversion
> between point types such a common operation that it's a performance
> bottleneck?
>

idk if it’s a performance bottleneck because i use tuples in my geometry
stack and i keep the bottom 2 levels in the same module but it cannot be
good. a lot of the geometry code I write sits atop 2 or 3 other layers of
geometry code beneath it, and it interops with geometry APIs in other
libraries. for example it might be organized like

[ Client geometry code ] ←→ [ Library geometry code ] (example:
Voronoi.voronoi(_:), Noise.perlin(_:_:))
   [ Procedurally generated geometry ] (example:
makeSphere(resolution:))
   [Matrices and projections ] (example:
Geometry.clockwise(_:_:center:normal:))
   [   Math  ] (example: Math.cross(_:_:))

converting at every boundary seems like something to avoid. not to mention
the sheer amount of boilerplate all those conversions produce.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Xiaodi Wu via swift-evolution]

On Thu, Nov 23, 2017 at 16:45 Kelvin Ma via swift-evolution <
swift-evolution@swift.org> wrote:

>
>
> On Thu, Nov 23, 2017 at 12:32 PM, Tino Heth <2...@gmx.de> wrote:
>
>>
>> a good idea on paper, a disastrous one in practice. What happens if every
>> geometry library declares their own Point type?
>>
>> That would be ugly („disastrous“ imho is a little bit to strong — C++
>> had/has similar issues, and other languages as well)
>> But if there would be a simple Point struct in a library that is popular
>> (could be achieved by shipping it alongside the stdlib), this problem would
>> be solved (there has been a pitch lately, but I guess it faded away
>> silently).
>>
>
> it’s ugly in C++ and disastrous in Swift because C++ has fixed layout
> guarantees and everyone agrees that z comes after y comes after x, so you
> can unsafe-bitcast the foreign C++ points into your own points “for free”.
> you can’t do the same thing in Swift
>

Why do you need to have this ability to unsafe bitcast? Is interconversion
between point types such a common operation that it's a performance
bottleneck?
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Kelvin Ma via swift-evolution]

On Thu, Nov 23, 2017 at 5:45 PM, Kelvin Ma  wrote:

>
>
> On Thu, Nov 23, 2017 at 12:32 PM, Tino Heth <2...@gmx.de> wrote:
>
>>
>> a good idea on paper, a disastrous one in practice. What happens if every
>> geometry library declares their own Point type?
>>
>> That would be ugly („disastrous“ imho is a little bit to strong — C++
>> had/has similar issues, and other languages as well)
>> But if there would be a simple Point struct in a library that is popular
>> (could be achieved by shipping it alongside the stdlib), this problem would
>> be solved (there has been a pitch lately, but I guess it faded away
>> silently).
>>
>
> it’s ugly in C++ and disastrous in Swift because C++ has fixed layout
> guarantees and everyone agrees that z comes after y comes after x, so you
> can unsafe-bitcast the foreign C++ points into your own points “for free”.
> you can’t do the same thing in Swift
>

ps i remember that pitch because i’m pretty sure i was the one that pitched
that. consensus seemed it was too high level for inclusion (even though
having it at the stdlib level would do wonders for things like SIMD) and
everyone got distracted by “integers as generic parameters” (because we
love `Vector<3>` ig) because everything on this list always devolves into
“but this is *really* a problem with the *generics system*” and since no
one knows how to fix the generics system everyone calls it a day and
forgets about the original issue
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Kelvin Ma via swift-evolution]

On Thu, Nov 23, 2017 at 12:32 PM, Tino Heth <2...@gmx.de> wrote:

>
> a good idea on paper, a disastrous one in practice. What happens if every
> geometry library declares their own Point type?
>
> That would be ugly („disastrous“ imho is a little bit to strong — C++
> had/has similar issues, and other languages as well)
> But if there would be a simple Point struct in a library that is popular
> (could be achieved by shipping it alongside the stdlib), this problem would
> be solved (there has been a pitch lately, but I guess it faded away
> silently).
>

it’s ugly in C++ and disastrous in Swift because C++ has fixed layout
guarantees and everyone agrees that z comes after y comes after x, so you
can unsafe-bitcast the foreign C++ points into your own points “for free”.
you can’t do the same thing in Swift
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Tino Heth via swift-evolution]

> a good idea on paper, a disastrous one in practice. What happens if every 
> geometry library declares their own Point type?
That would be ugly („disastrous“ imho is a little bit to strong — C++ had/has 
similar issues, and other languages as well)
But if there would be a simple Point struct in a library that is popular (could 
be achieved by shipping it alongside the stdlib), this problem would be solved 
(there has been a pitch lately, but I guess it faded away silently).___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Howard Lovatt via swift-evolution]

You don't necessarily need variadic generics to enable tuples to be nominal
types. Though you do need some changes to the generic type system. One
possibility is:

struct Tuple_0_Int_1_Int: Collection /*where T0: T, T1: T*/
{ // Mangle name. Need covariant generics to enable constraint of T0 and T1.
typealias Element = T
typealias Index = Int
typealias SubSequence = Slice
var _0_: T/*0*/ // Unique name.
var _1_: T/*1*/ // Unique name.
let startIndex: Int = 0
let endIndex: Int = 2
subscript(position: Int) -> T {
switch position {
case 0: return _0_
case 1: return _1_
default: fatalError("Index out of bounds (must be 0 or 1).")
}
}
func index(after i: Int) -> Int {
return i + 1
}
}

// Ideally:
//   1. Extension on Tuple_0_Int_1_Int (SE-143).
//   2. Collection extension rather than on every Tuple (SE-143 extension).
func == (lhs: Tuple_0_Int_1_Int, rhs: Tuple_0_Int_1_Int) -> Bool
where T: Equatable {
let size = lhs.count
guard size == rhs.count else {
return false
}
for i in 0 ..< size {
guard lhs[i] == rhs[i] else {
return false
}
}
return true
}


The above is valid Swift 4, but I really want to be able to say:

   1. `struct Tuple_0_Int_1_Int: Collection where T0: T, T1: T`,
   i.e. covariant generics.
   2. Ideally SE143+ also, so that I can extend Collection to implement
   Equatable, Hashable, etc.

Note:

   1. Tuples extend Collection, not MutableCollection.
   2. T is the base type of T0 and T1.
   3. A Collection of T is sufficient to write interesting generic
   algorithms; equals, etc.


  -- Howard.

On 23 November 2017 at 11:50, David Sweeris via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Nov 21, 2017, at 22:54, Douglas Gregor via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On Nov 21, 2017, at 10:48 PM, David Hart  wrote:
>
>
>
> On 22 Nov 2017, at 07:41, Douglas Gregor via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
>
> On Nov 21, 2017, at 10:37 PM, Chris Lattner  wrote:
>
> On Nov 21, 2017, at 9:25 PM, Douglas Gregor  wrote:
>
> Or alternatively, one could decide to make the generics system *only and
> forever* work on nominal types, and make the syntactic sugar just be sugar
> for named types like Swift.Tuple, Function, and Optional.  Either design
> could work.
>
>
> We don’t have a way to make it work for function types, though, because of
> parameter-passing conventions. Well, assuming we don’t invent something
> that allows:
>
> Function
>
> to exist in the type system. Tuple labels have a similar problem.
>
>
> I’m totally aware of that and mentioned it upthread.
>
>
> Eh, sorry I missed it.
>
>  There are various encoding tricks that could make this work depending on
> how you want to stretch the current generics system…
>
>
> I think it’s straightforward and less ugly to make structural types allow
> extensions and protocol conformances.
>
>
> Can somebody explain to me what is less ugly about that? I would have
> naturally thought that the language would be simpler as a whole if there
> only existed nominal types and all structural types were just sugar over
> them.
>
>
> See Thorsten’s response with, e.g.,
>
>   Function
>
> which handles “inout” by adding wrappers around the parameter types (which
> one would have to cope with in any user of Function), but still doesn’t
> handle argument labels. To handle argument labels, we would need something
> like strings as generic arguments.
>
>
> Oh, good! A use case for “literals as generic parameters” *other* than
> Vectors and Fixed-Size Arrays!
>
> - Dave Sweeris
>
> ___
> 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] Synthesizing Equatable, Hashable, and Comparable for tuple types

[David Sweeris via swift-evolution]

> On Nov 21, 2017, at 22:54, Douglas Gregor via swift-evolution 
>  wrote:
> 
>> On Nov 21, 2017, at 10:48 PM, David Hart  wrote:
>> 
>> 
>> 
>> On 22 Nov 2017, at 07:41, Douglas Gregor via swift-evolution 
>>  wrote:
>> 
>>> 
>>> 
 On Nov 21, 2017, at 10:37 PM, Chris Lattner  wrote:
 
 On Nov 21, 2017, at 9:25 PM, Douglas Gregor  wrote:
>> Or alternatively, one could decide to make the generics system *only and 
>> forever* work on nominal types, and make the syntactic sugar just be 
>> sugar for named types like Swift.Tuple, Function, and Optional.  Either 
>> design could work.
> 
> We don’t have a way to make it work for function types, though, because 
> of parameter-passing conventions. Well, assuming we don’t invent 
> something that allows:
> 
>   Function
> 
> to exist in the type system. Tuple labels have a similar problem.
 
 I’m totally aware of that and mentioned it upthread. 
>>> 
>>> Eh, sorry I missed it.
>>> 
  There are various encoding tricks that could make this work depending on 
 how you want to stretch the current generics system…
>>> 
>>> I think it’s straightforward and less ugly to make structural types allow 
>>> extensions and protocol conformances.
>> 
>> Can somebody explain to me what is less ugly about that? I would have 
>> naturally thought that the language would be simpler as a whole if there 
>> only existed nominal types and all structural types were just sugar over 
>> them.
> 
> See Thorsten’s response with, e.g.,
> 
> Function
> 
> which handles “inout” by adding wrappers around the parameter types (which 
> one would have to cope with in any user of Function), but still doesn’t 
> handle argument labels. To handle argument labels, we would need something 
> like strings as generic arguments.

Oh, good! A use case for “literals as generic parameters” other than Vectors 
and Fixed-Size Arrays!

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

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Mike Kluev via swift-evolution]

on Date: Tue, 21 Nov 2017 22:54:21 -0800 Douglas Gregor 
wrote:

> On Nov 21, 2017, at 10:48 PM, David Hart  wrote:
> >
> > On 22 Nov 2017, at 07:41, Douglas Gregor via swift-evolution <
> swift-evolution@swift.org > wrote:
> >
> >>
> >> I think it’s straightforward and less ugly to make structural types
> allow extensions and protocol conformances.
> >
> > Can somebody explain to me what is less ugly about that? I would have
> naturally thought that the language would be simpler as a whole if there
> only existed nominal types and all structural types were just sugar over
> them.
>
> See Thorsten’s response with, e.g.,
>
>   Function
>
> which handles “inout” by adding wrappers around the parameter types (which
> one would have to cope with in any user of Function), but still doesn’t
> handle argument labels. To handle argument labels, we would need something
> like strings as generic arguments. We’d also need to handle calling
> conventions and anything else we invent for function types.
>
>
can you outline how extensions and protocol conformances might look
for structural types? to compare the ugliness of both approaches.

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

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Howard Lovatt via swift-evolution]

I would defend turning tuples into structs (change from structural type to
nominal type). This is a much better story for programmers, compare the two
stories:

   1. Tuples are just syntax sugar for simple structs.
   2. Tuples are sort of like structs but there is a list of things tuples
   can do that structs can't and a list of things structs can do and tuples
   can't.

I think unification can be achieved with some name mangling (Chris Lattner
noted this previously - I am just spelling out one scheme), e.g.:

// var a = (zero: 0, one: 1)
public struct Tuple_zero_Int_one_Int { // Mangle name.
public var zero: Int
public var one: Int
}
var a = Tuple_zero_Int_one_Int(zero: 0, one: 1)
// a.0 = -1
a.zero = -1

// var b = (0, 1)
public struct Tuple_0_Int_1_Int { // Mangle name.
public var _0_: Int // Unique name.
public var _1_: Int // Unique name.
}
var b = Tuple_0_Int_1_Int(_0_: 0, _1_: 1)
// a = b
a = Tuple_zero_Int_one_Int(zero: b._0_, one: b._1_)


Implicit in the above transformation is:

   1. struct and tuple have the same memory layout.
   2. `.0` access the 1st stored property of a struct, `.1` the 2nd, etc.


  -- Howard.

On 22 November 2017 at 18:02, David Hart via swift-evolution <
swift-evolution@swift.org> wrote:

>
>
> On 22 Nov 2017, at 07:54, Douglas Gregor  wrote:
>
>
>
> On Nov 21, 2017, at 10:48 PM, David Hart  wrote:
>
>
>
> On 22 Nov 2017, at 07:41, Douglas Gregor via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
>
> On Nov 21, 2017, at 10:37 PM, Chris Lattner  wrote:
>
> On Nov 21, 2017, at 9:25 PM, Douglas Gregor  wrote:
>
> Or alternatively, one could decide to make the generics system *only and
> forever* work on nominal types, and make the syntactic sugar just be sugar
> for named types like Swift.Tuple, Function, and Optional.  Either design
> could work.
>
>
> We don’t have a way to make it work for function types, though, because of
> parameter-passing conventions. Well, assuming we don’t invent something
> that allows:
>
> Function
>
> to exist in the type system. Tuple labels have a similar problem.
>
>
> I’m totally aware of that and mentioned it upthread.
>
>
> Eh, sorry I missed it.
>
>  There are various encoding tricks that could make this work depending on
> how you want to stretch the current generics system…
>
>
> I think it’s straightforward and less ugly to make structural types allow
> extensions and protocol conformances.
>
>
> Can somebody explain to me what is less ugly about that? I would have
> naturally thought that the language would be simpler as a whole if there
> only existed nominal types and all structural types were just sugar over
> them.
>
>
> See Thorsten’s response with, e.g.,
>
>   Function
>
> which handles “inout” by adding wrappers around the parameter types (which
> one would have to cope with in any user of Function), but still doesn’t
> handle argument labels. To handle argument labels, we would need something
> like strings as generic arguments. We’d also need to handle calling
> conventions and anything else we invent for function types.
>
>
> Oh ok, I get. The ugliness comes from trying to shoehorn structural types
> into nominal types.
>
> - Doug
>
>
>
>
> ___
> 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] Synthesizing Equatable, Hashable, and Comparable for tuple types

[David Hart via swift-evolution]

> On 22 Nov 2017, at 07:54, Douglas Gregor  wrote:
> 
> 
> 
>> On Nov 21, 2017, at 10:48 PM, David Hart > > wrote:
>> 
>> 
>> 
>> On 22 Nov 2017, at 07:41, Douglas Gregor via swift-evolution 
>> > wrote:
>> 
>>> 
>>> 
 On Nov 21, 2017, at 10:37 PM, Chris Lattner > wrote:
 
 On Nov 21, 2017, at 9:25 PM, Douglas Gregor > wrote:
>> Or alternatively, one could decide to make the generics system *only and 
>> forever* work on nominal types, and make the syntactic sugar just be 
>> sugar for named types like Swift.Tuple, Function, and Optional.  Either 
>> design could work.
> 
> We don’t have a way to make it work for function types, though, because 
> of parameter-passing conventions. Well, assuming we don’t invent 
> something that allows:
> 
>   Function
> 
> to exist in the type system. Tuple labels have a similar problem.
 
 I’m totally aware of that and mentioned it upthread. 
>>> 
>>> Eh, sorry I missed it.
>>> 
  There are various encoding tricks that could make this work depending on 
 how you want to stretch the current generics system…
>>> 
>>> I think it’s straightforward and less ugly to make structural types allow 
>>> extensions and protocol conformances.
>> 
>> Can somebody explain to me what is less ugly about that? I would have 
>> naturally thought that the language would be simpler as a whole if there 
>> only existed nominal types and all structural types were just sugar over 
>> them.
> 
> See Thorsten’s response with, e.g.,
> 
> Function
> 
> which handles “inout” by adding wrappers around the parameter types (which 
> one would have to cope with in any user of Function), but still doesn’t 
> handle argument labels. To handle argument labels, we would need something 
> like strings as generic arguments. We’d also need to handle calling 
> conventions and anything else we invent for function types.

Oh ok, I get. The ugliness comes from trying to shoehorn structural types into 
nominal types.

>   - Doug
> 
> 

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

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[David Hart via swift-evolution]

> On 22 Nov 2017, at 07:48, David Hart via swift-evolution 
>  wrote:
> 
> 
> 
> On 22 Nov 2017, at 07:41, Douglas Gregor via swift-evolution 
> > wrote:
> 
>> 
>> 
>>> On Nov 21, 2017, at 10:37 PM, Chris Lattner >> > wrote:
>>> 
>>> On Nov 21, 2017, at 9:25 PM, Douglas Gregor >> > wrote:
> Or alternatively, one could decide to make the generics system *only and 
> forever* work on nominal types, and make the syntactic sugar just be 
> sugar for named types like Swift.Tuple, Function, and Optional.  Either 
> design could work.
 
 We don’t have a way to make it work for function types, though, because of 
 parameter-passing conventions. Well, assuming we don’t invent something 
 that allows:
 
Function
 
 to exist in the type system. Tuple labels have a similar problem.
>>> 
>>> I’m totally aware of that and mentioned it upthread.
>> 
>> Eh, sorry I missed it.
>> 
>>>  There are various encoding tricks that could make this work depending on 
>>> how you want to stretch the current generics system…
>> 
>> I think it’s straightforward and less ugly to make structural types allow 
>> extensions and protocol conformances.
> 
> Can somebody explain to me what is less ugly about that? I would have 
> naturally thought that the language would be simpler as a whole if there only 
> existed nominal types and all structural types were just sugar over them.

What confuses me is that I always thought that T? was sugar for Optional by 
design, and found that to be quite elegant. But now you’re telling me that its 
just a hack to allow conformance on Optionals until it can be made structural. 
I would have thought that it would be cleaner to have specific concepts 
(optionals, tuples, etc…) represented in terms of more general concepts (enum, 
struct) so that the compiler had less to reason about. I’m just trying to 
understand :-)

>>  - Doug
>> 
>> 
>> ___
>> 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] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Douglas Gregor via swift-evolution]

> On Nov 21, 2017, at 10:48 PM, David Hart  wrote:
> 
> 
> 
> On 22 Nov 2017, at 07:41, Douglas Gregor via swift-evolution 
> > wrote:
> 
>> 
>> 
>>> On Nov 21, 2017, at 10:37 PM, Chris Lattner >> > wrote:
>>> 
>>> On Nov 21, 2017, at 9:25 PM, Douglas Gregor >> > wrote:
> Or alternatively, one could decide to make the generics system *only and 
> forever* work on nominal types, and make the syntactic sugar just be 
> sugar for named types like Swift.Tuple, Function, and Optional.  Either 
> design could work.
 
 We don’t have a way to make it work for function types, though, because of 
 parameter-passing conventions. Well, assuming we don’t invent something 
 that allows:
 
Function
 
 to exist in the type system. Tuple labels have a similar problem.
>>> 
>>> I’m totally aware of that and mentioned it upthread. 
>> 
>> Eh, sorry I missed it.
>> 
>>>  There are various encoding tricks that could make this work depending on 
>>> how you want to stretch the current generics system…
>> 
>> I think it’s straightforward and less ugly to make structural types allow 
>> extensions and protocol conformances.
> 
> Can somebody explain to me what is less ugly about that? I would have 
> naturally thought that the language would be simpler as a whole if there only 
> existed nominal types and all structural types were just sugar over them.

See Thorsten’s response with, e.g.,

  Function

which handles “inout” by adding wrappers around the parameter types (which one 
would have to cope with in any user of Function), but still doesn’t handle 
argument labels. To handle argument labels, we would need something like 
strings as generic arguments. We’d also need to handle calling conventions and 
anything else we invent for function types.

- Doug


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

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[David Hart via swift-evolution]

> On 22 Nov 2017, at 07:41, Douglas Gregor via swift-evolution 
>  wrote:
> 
> 
> 
>> On Nov 21, 2017, at 10:37 PM, Chris Lattner  wrote:
>> 
>> On Nov 21, 2017, at 9:25 PM, Douglas Gregor  wrote:
 Or alternatively, one could decide to make the generics system *only and 
 forever* work on nominal types, and make the syntactic sugar just be sugar 
 for named types like Swift.Tuple, Function, and Optional.  Either design 
 could work.
>>> 
>>> We don’t have a way to make it work for function types, though, because of 
>>> parameter-passing conventions. Well, assuming we don’t invent something 
>>> that allows:
>>> 
>>> Function
>>> 
>>> to exist in the type system. Tuple labels have a similar problem.
>> 
>> I’m totally aware of that and mentioned it upthread.
> 
> Eh, sorry I missed it.
> 
>>  There are various encoding tricks that could make this work depending on 
>> how you want to stretch the current generics system…
> 
> I think it’s straightforward and less ugly to make structural types allow 
> extensions and protocol conformances.

Can somebody explain to me what is less ugly about that? I would have naturally 
thought that the language would be simpler as a whole if there only existed 
nominal types and all structural types were just sugar over them.

>   - Doug
> 
> 
> ___
> 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] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Douglas Gregor via swift-evolution]

> On Nov 21, 2017, at 10:37 PM, Chris Lattner  wrote:
> 
> On Nov 21, 2017, at 9:25 PM, Douglas Gregor  > wrote:
>>> Or alternatively, one could decide to make the generics system *only and 
>>> forever* work on nominal types, and make the syntactic sugar just be sugar 
>>> for named types like Swift.Tuple, Function, and Optional.  Either design 
>>> could work.
>> 
>> We don’t have a way to make it work for function types, though, because of 
>> parameter-passing conventions. Well, assuming we don’t invent something that 
>> allows:
>> 
>>  Function
>> 
>> to exist in the type system. Tuple labels have a similar problem.
> 
> I’m totally aware of that and mentioned it upthread.

Eh, sorry I missed it.

>  There are various encoding tricks that could make this work depending on how 
> you want to stretch the current generics system…

I think it’s straightforward and less ugly to make structural types allow 
extensions and protocol conformances.

- Doug


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

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Chris Lattner via swift-evolution]

On Nov 21, 2017, at 9:25 PM, Douglas Gregor  wrote:
>> Or alternatively, one could decide to make the generics system *only and 
>> forever* work on nominal types, and make the syntactic sugar just be sugar 
>> for named types like Swift.Tuple, Function, and Optional.  Either design 
>> could work.
> 
> We don’t have a way to make it work for function types, though, because of 
> parameter-passing conventions. Well, assuming we don’t invent something that 
> allows:
> 
>   Function
> 
> to exist in the type system. Tuple labels have a similar problem.

I’m totally aware of that and mentioned it upthread.  There are various 
encoding tricks that could make this work depending on how you want to stretch 
the current generics system…

-Chris


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

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Thorsten Seitz via swift-evolution]

> Am 22.11.2017 um 06:25 schrieb Douglas Gregor via swift-evolution 
> :
> 
> 
> 
>>> On Nov 21, 2017, at 9:21 PM, Chris Lattner  wrote:
>>> 
>>> 
>>> 
>>> On Nov 21, 2017, at 7:19 PM, Douglas Gregor via swift-evolution 
>>>  wrote:
>>> 
>>> 
>>> 
>>> Sent from my iPhone
>>> 
 On Nov 21, 2017, at 3:46 PM, Tony Allevato  wrote:
 
 Does that mean that once structural types can conform to protocols, would 
 the core team want to remove Optional as a nominal type and just use “T?”? 
>>> 
>>> Yes; at least, it’s a direction we’ve discussed a number of times. 
>>> 
 Or has that ship sailed because of source compatibility and you just don’t 
 want to introduce any new nominals that shadow structurals?
>>> 
>>> typealias Optional = T?
>>> 
>>> Should address source compatibility. 
>> 
>> Or alternatively, one could decide to make the generics system *only and 
>> forever* work on nominal types, and make the syntactic sugar just be sugar 
>> for named types like Swift.Tuple, Function, and Optional.  Either design 
>> could work.
> 
> We don’t have a way to make it work for function types, though, because of 
> parameter-passing conventions. Well, assuming we don’t invent something that 
> allows:
> 
>   Function
> 
> to exist in the type system. Tuple labels have a similar problem.
> 

Just throwing an idea out: what about

  Function

or

  Function, Param>

The latter assuming we had generics with value parameters (which is another 
common topic on this list) and defaults.
The first example might have the advantage of making use of inheritance between 
InoutParam and Param (which would require variance for type parameters, another 
common topic).

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

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Douglas Gregor via swift-evolution]

> On Nov 21, 2017, at 9:21 PM, Chris Lattner  wrote:
> 
> 
> 
>> On Nov 21, 2017, at 7:19 PM, Douglas Gregor via swift-evolution 
>> > wrote:
>> 
>> 
>> 
>> Sent from my iPhone
>> 
>> On Nov 21, 2017, at 3:46 PM, Tony Allevato > > wrote:
>> 
>>> Does that mean that once structural types can conform to protocols, would 
>>> the core team want to remove Optional as a nominal type and just use “T?”? 
>> 
>> Yes; at least, it’s a direction we’ve discussed a number of times. 
>> 
>>> Or has that ship sailed because of source compatibility and you just don’t 
>>> want to introduce any new nominals that shadow structurals?
>> 
>> typealias Optional = T?
>> 
>> Should address source compatibility. 
> 
> Or alternatively, one could decide to make the generics system *only and 
> forever* work on nominal types, and make the syntactic sugar just be sugar 
> for named types like Swift.Tuple, Function, and Optional.  Either design 
> could work.

We don’t have a way to make it work for function types, though, because of 
parameter-passing conventions. Well, assuming we don’t invent something that 
allows:

Function

to exist in the type system. Tuple labels have a similar problem.

- Doug


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

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Chris Lattner via swift-evolution]

> On Nov 21, 2017, at 7:19 PM, Douglas Gregor via swift-evolution 
>  wrote:
> 
> 
> 
> Sent from my iPhone
> 
> On Nov 21, 2017, at 3:46 PM, Tony Allevato  > wrote:
> 
>> Does that mean that once structural types can conform to protocols, would 
>> the core team want to remove Optional as a nominal type and just use “T?”?
> 
> Yes; at least, it’s a direction we’ve discussed a number of times. 
> 
>> Or has that ship sailed because of source compatibility and you just don’t 
>> want to introduce any new nominals that shadow structurals?
> 
> typealias Optional = T?
> 
> Should address source compatibility. 

Or alternatively, one could decide to make the generics system *only and 
forever* work on nominal types, and make the syntactic sugar just be sugar for 
named types like Swift.Tuple, Function, and Optional.  Either design could work.

-Chris


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

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Douglas Gregor via swift-evolution]

Sent from my iPhone

> On Nov 21, 2017, at 3:46 PM, Tony Allevato  wrote:
> 
> Does that mean that once structural types can conform to protocols, would the 
> core team want to remove Optional as a nominal type and just use “T?”?

Yes; at least, it’s a direction we’ve discussed a number of times. 

> Or has that ship sailed because of source compatibility and you just don’t 
> want to introduce any new nominals that shadow structurals?

typealias Optional = T?

Should address source compatibility. 

  - Doug

> 
>> On Tue, Nov 21, 2017 at 3:10 PM Douglas Gregor via swift-evolution 
>>  wrote:
>> 
>> 
 On Nov 21, 2017, at 3:05 PM, Slava Pestov  wrote:
 
 
 
 On Nov 21, 2017, at 6:02 PM, David Hart  wrote:
 
 Can somebody explain to me what are 
  nominal and structural types and why Optional should really be a 
 structural type?
>>> 
>>> Nominal types are structs, enums, protocols and classes. They have 
>>> declarations in source and are uniquely identified by their name. 
>>> Structural types are functions, meta types, protocol compositions, and 
>>> tuples.
>>> 
>>> The distinction is not as clear as you might think because as Chris said, 
>>> you can imagine tuple being implemented as ‘struct Tuple’, similarly 
>>> functions and meta types could also be written as such. It is mostly a 
>>> syntactic distinction in the language, but it has far-reaching consequences 
>>> in internal representations, which is why for now it would be tricky to 
>>> have structural types conform to protocols.
>> 
>> Right. Optionals are a tricky case because we wanted them to be nominal so 
>> we could write extensions on them and make them conform to protocols, but, 
>> they’re so integral to the language that they are really treated like a 
>> structural type.
>> 
>>  - Doug
>> 
>> 
>> ___
>> 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] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Tony Allevato via swift-evolution]

Does that mean that once structural types can conform to protocols, would
the core team want to remove Optional as a nominal type and just use “T?”?
Or has that ship sailed because of source compatibility and you just don’t
want to introduce any new nominals that shadow structurals?

On Tue, Nov 21, 2017 at 3:10 PM Douglas Gregor via swift-evolution <
swift-evolution@swift.org> wrote:

>
>
> On Nov 21, 2017, at 3:05 PM, Slava Pestov  wrote:
>
>
>
> On Nov 21, 2017, at 6:02 PM, David Hart  wrote:
>
> Can somebody explain to me what are
>  nominal and structural types and why Optional should really be a
> structural type?
>
>
> Nominal types are structs, enums, protocols and classes. They have
> declarations in source and are uniquely identified by their name.
> Structural types are functions, meta types, protocol compositions, and
> tuples.
>
> The distinction is not as clear as you might think because as Chris said,
> you can imagine tuple being implemented as ‘struct Tuple’, similarly
> functions and meta types could also be written as such. It is mostly a
> syntactic distinction in the language, but it has far-reaching consequences
> in internal representations, which is why for now it would be tricky to
> have structural types conform to protocols.
>
>
> Right. Optionals are a tricky case because we wanted them to be nominal so
> we could write extensions on them and make them conform to protocols, but,
> they’re so integral to the language that they are really treated like a
> structural type.
>
> - Doug
>
>
> ___
> 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] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Douglas Gregor via swift-evolution]

> On Nov 21, 2017, at 3:05 PM, Slava Pestov  wrote:
> 
> 
> 
>> On Nov 21, 2017, at 6:02 PM, David Hart > > wrote:
>> 
>> Can somebody explain to me what are 
>>  nominal and structural types and why Optional should really be a structural 
>> type?
> 
> Nominal types are structs, enums, protocols and classes. They have 
> declarations in source and are uniquely identified by their name. Structural 
> types are functions, meta types, protocol compositions, and tuples.
> 
> The distinction is not as clear as you might think because as Chris said, you 
> can imagine tuple being implemented as ‘struct Tuple’, similarly 
> functions and meta types could also be written as such. It is mostly a 
> syntactic distinction in the language, but it has far-reaching consequences 
> in internal representations, which is why for now it would be tricky to have 
> structural types conform to protocols.

Right. Optionals are a tricky case because we wanted them to be nominal so we 
could write extensions on them and make them conform to protocols, but, they’re 
so integral to the language that they are really treated like a structural type.

- Doug


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

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Slava Pestov via swift-evolution]

> On Nov 21, 2017, at 6:02 PM, David Hart  wrote:
> 
> Can somebody explain to me what are 
>  nominal and structural types and why Optional should really be a structural 
> type?

Nominal types are structs, enums, protocols and classes. They have declarations 
in source and are uniquely identified by their name. Structural types are 
functions, meta types, protocol compositions, and tuples.

The distinction is not as clear as you might think because as Chris said, you 
can imagine tuple being implemented as ‘struct Tuple’, similarly functions 
and meta types could also be written as such. It is mostly a syntactic 
distinction in the language, but it has far-reaching consequences in internal 
representations, which is why for now it would be tricky to have structural 
types conform to protocols.

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

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[David Hart via swift-evolution]

> On 21 Nov 2017, at 22:44, Douglas Gregor  wrote:
> 
> 
> 
>>> On Nov 20, 2017, at 10:31 PM, Chris Lattner  wrote:
>>> 
>>> 
>>> 
>>> On Nov 20, 2017, at 10:24 PM, David Hart  wrote:
>>> 
>>> 
>>> 
>>> On 21 Nov 2017, at 03:17, Chris Lattner via swift-evolution 
>>>  wrote:
>>> 
 Yes, I agree, we need variadic generics before we can have tuples conform 
 :-(
 
 At the end of the day, you want to be able to treat “(U, V, W)” as sugar 
 for Tuple just like we handle array sugar.  When that is possible, 
 Tuple is just a type like any other in the system (but we need variadics 
 to express it).
>>> 
>>> Eye-opening! Now I understand how important variadic generics are. Somebody 
>>> should add that example to the Generics Manifesto.
> 
> It’s in there under “extensions of structural types”, here: 
> https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#extensions-of-structural-types
> 
> with this example:
> 
>   extension<...Elements : Equatable> (Elements...) : Equatable { // 
> extending the tuple type "(Elements...)" to be Equatable
> }
> 
>>> Questions:
>>> 
>>> • Doesn’t this simplification of the type system hoist Variadic Generics 
>>> back up the list of priorities?
>> 
>> Not above conditional and recursive conformances.
> 
> Right, and we don’t have bandwidth to take on Another Major Generics Feature 
> this year.
> 
>> 
>>> • Would it be desirable to implement them before ABI stability to “remove” 
>>> tuples from the ABI?
> 
> Tuples are structural types in the ABI (and type system), and should remain 
> that way. So, I disagree with Chris’s suggestion that (U, V, W) will become 
> Tuple. The most relevant comparison today is Optional, which is 
> technically a nominal type but is treated as a special case basically 
> everywhere in the compiler (and ABI) because it should have been a structural 
> type. I expect optionals to become structural types in the future (the ABI is 
> designed for that) and tuples to remain structural types.

Can somebody explain to me what are 
 nominal and structural types and why Optional should really be a structural 
type?

>>> • If not, is the current ABI already flexible enough to support them if 
>>> they are implemented later on?
>> 
>> I am not the expert on this (Doug Gregor is), but I think we can add it 
>> later in an ABI additive way.
> 
> Yes, we can add it to the ABI later.
> 
>   - Doug
> 
>> 
>> -Chris
>> 
>> 
>> 
>> 
>> 
 Once you have that, then you could write conformances in general, as well 
 as conditional conformances that depend on (e.g.) all the element types 
 being equatable.
 
 
 We also need that to allow functions conform to protocols, because 
 functions aren’t "T1->T2” objects, the actual parameter list is an 
 inseparable part of the function type, and the parameter list needs 
 variadics.
 
 -Chris
 
> On Nov 20, 2017, at 6:10 PM, Slava Pestov  wrote:
> 
> Ignoring synthesized conformances for a second, think about how you would 
> manually implement a conformance of a tuple type to a protocol. You would 
> need some way to statically “iterate” over all the component types of the 
> tuple — in fact this is the same as having variadic generics.
> 
> If we had variadic generics, we could implement tuples conforming to 
> protocols, either by refactoring the compiler to allow conforming types 
> to be non-nominal, or by reworking things so that a tuple is a nominal 
> type with a single variadic generic parameter.
> 
> Slava
> 
>> On Nov 20, 2017, at 9:06 PM, Tony Allevato via swift-evolution 
>>  wrote:
>> 
>> This is something I've wanted to look at for a while. A few weeks ago I 
>> pushed out https://github.com/apple/swift/pull/12598 to extend the 
>> existing synthesis to handle structs/enums when a field/payload has a 
>> tuple of things that are Equatable/Hashable, and in that PR it was 
>> (rightly) observed, as Chris just did, that making tuples conform to 
>> protocols would be a more general solution that solves the same problem 
>> you want to solve here.
>> 
>> I'd love to dig into this more, but last time I experimented with it I 
>> got stuck on places where the protocol conformance machinery expects 
>> NominalTypeDecls, and I wasn't sure where the right place to hoist that 
>> logic up to was (since tuples don't have a corresponding Decl from what 
>> I can tell). Any pointers?
>> 
>>> On Mon, Nov 20, 2017 at 5:51 PM Chris Lattner via swift-evolution 
>>>  wrote:
 On Nov 20, 2017, at 5:48 PM, Kelvin Ma  wrote:
 the end goal here is to use tuples as a compatible currency type, to 

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Douglas Gregor via swift-evolution]

> On Nov 20, 2017, at 6:07 PM, Tony Allevato via swift-evolution 
>  wrote:
> 
> This is something I've wanted to look at for a while. A few weeks ago I 
> pushed out https://github.com/apple/swift/pull/12598 
>  to extend the existing synthesis 
> to handle structs/enums when a field/payload has a tuple of things that are 
> Equatable/Hashable, and in that PR it was (rightly) observed, as Chris just 
> did, that making tuples conform to protocols would be a more general solution 
> that solves the same problem you want to solve here.
> 
> I'd love to dig into this more, but last time I experimented with it I got 
> stuck on places where the protocol conformance machinery expects 
> NominalTypeDecls, and I wasn't sure where the right place to hoist that logic 
> up to was (since tuples don't have a corresponding Decl from what I can 
> tell). Any pointers?

Tuples won’t have a corresponding Decl, because they’re structural. The 
protocol conformance machinery (e.g., the ConformanceLookupTable) would need to 
be generalized to cover the various kinds of types that can be made to conform 
to a protocol:  nominal types, function types, tuple types, metatypes, and 
protocol composition types. Similarly, the assumption that one can only write 
an extension on a nominal type is fairly widespread in the compiler.

All of these are fine refactors along the way, and could be used to improve the 
compiler long before we’re ready to turn it into a user-facing language feature.

- Doug

> 
> On Mon, Nov 20, 2017 at 5:51 PM Chris Lattner via swift-evolution 
> > wrote:
> On Nov 20, 2017, at 5:48 PM, Kelvin Ma  > wrote:
>> the end goal here is to use tuples as a compatible currency type, to that 
>> end it makes sense for these three protocols to be handled as “compiler 
>> magic” and to disallow users from manually defining tuple conformances 
>> themselves. i’m not a fan of compiler magic, but Equatable, Hashable, and 
>> Comparable are special because they’re the basis for a lot of standard 
>> library functionality so i think the benefits of making this a special 
>> supported case outweigh the additional language opacity.
> 
> I understand your goal, but that compiler magic can’t exist until there is 
> something to hook it into.  Tuples can’t conform to protocols right now, so 
> there is nothing that can be synthesized.
> 
> -Chris
> 
> 
>> 
>> On Mon, Nov 20, 2017 at 8:42 PM, Chris Lattner > > wrote:
>> 
>>> On Nov 20, 2017, at 5:39 PM, Kelvin Ma via swift-evolution 
>>> > wrote:
>>> 
>>> when SE-185 
>>> 
>>>  went through swift evolution, it was agreed that the next logical step 
>>>  is 
>>> synthesizing these conformances for tuple types, though it was left out of 
>>> the original proposal to avoid mission creep. I think now is the time to 
>>> start thinking about this. i’m also tacking on Comparable to the other two 
>>> protocols because there is precedent in the language from SE-15 
>>> 
>>>  that tuple comparison is something that makes sense to write.
>>> 
>>> EHC conformance is even more important for tuples than it is for structs 
>>> because tuples effectively have no workaround whereas in structs, you could 
>>> just manually implement the conformance. 
>> 
>> In my opinion, you’re approaching this from the wrong direction.  The 
>> fundamental problem here is that tuples can’t conform to a protocol.  If 
>> they could, synthesizing these conformances would be straight-forward.
>> 
>> If you’re interested in pushing this forward, the discussion is “how do 
>> non-nominal types like tuples and functions conform to protocols”?
>> 
>> -Chris
>> 
>> 
>> 
>> 
>> 
> ___
> 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] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Douglas Gregor via swift-evolution]

> On Nov 20, 2017, at 6:17 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> Yes, I agree, we need variadic generics before we can have tuples conform :-(

Well, we don’t *have* to have variadic generics to allow structural types to 
conform… it just composes really, really elegantly. One could certainly allow 
extensions of tuple types with fixed arity, which would then provide 
conditional conformances:

extension (T, U): Equatable {
  // ...
}

extension (T, U, V): Equatable {
  // ...
}

Yes, the variadic suggestion is more general and more elegant, but these are 
orthogonal features.

> At the end of the day, you want to be able to treat “(U, V, W)” as sugar for 
> Tuple just like we handle array sugar.  When that is possible, Tuple 
> is just a type like any other in the system (but we need variadics to express 
> it).
> 
> Once you have that, then you could write conformances in general, as well as 
> conditional conformances that depend on (e.g.) all the element types being 
> equatable.

As noted in my previous reply, we don’t need Tuple to make this work.

> We also need that to allow functions conform to protocols, because functions 
> aren’t "T1->T2” objects, the actual parameter list is an inseparable part of 
> the function type, and the parameter list needs variadics.

Variadics aren’t enough to fully generalize parameter lists, though, because 
they don’t capture calling conventions. It’s actually a bit of an issue for 
Swift, because something variadic like:

extension (Params…) -> Result { }

Isn’t going to work with “inout”, or with shared/owned (whatever is not the 
default).

- Doug

> 
> -Chris
> 
>> On Nov 20, 2017, at 6:10 PM, Slava Pestov > > wrote:
>> 
>> Ignoring synthesized conformances for a second, think about how you would 
>> manually implement a conformance of a tuple type to a protocol. You would 
>> need some way to statically “iterate” over all the component types of the 
>> tuple — in fact this is the same as having variadic generics.
>> 
>> If we had variadic generics, we could implement tuples conforming to 
>> protocols, either by refactoring the compiler to allow conforming types to 
>> be non-nominal, or by reworking things so that a tuple is a nominal type 
>> with a single variadic generic parameter.
>> 
>> Slava
>> 
>>> On Nov 20, 2017, at 9:06 PM, Tony Allevato via swift-evolution 
>>> > wrote:
>>> 
>>> This is something I've wanted to look at for a while. A few weeks ago I 
>>> pushed out https://github.com/apple/swift/pull/12598 
>>>  to extend the existing 
>>> synthesis to handle structs/enums when a field/payload has a tuple of 
>>> things that are Equatable/Hashable, and in that PR it was (rightly) 
>>> observed, as Chris just did, that making tuples conform to protocols would 
>>> be a more general solution that solves the same problem you want to solve 
>>> here.
>>> 
>>> I'd love to dig into this more, but last time I experimented with it I got 
>>> stuck on places where the protocol conformance machinery expects 
>>> NominalTypeDecls, and I wasn't sure where the right place to hoist that 
>>> logic up to was (since tuples don't have a corresponding Decl from what I 
>>> can tell). Any pointers?
>>> 
>>> On Mon, Nov 20, 2017 at 5:51 PM Chris Lattner via swift-evolution 
>>> > wrote:
>>> On Nov 20, 2017, at 5:48 PM, Kelvin Ma >> > wrote:
 the end goal here is to use tuples as a compatible currency type, to that 
 end it makes sense for these three protocols to be handled as “compiler 
 magic” and to disallow users from manually defining tuple conformances 
 themselves. i’m not a fan of compiler magic, but Equatable, Hashable, and 
 Comparable are special because they’re the basis for a lot of standard 
 library functionality so i think the benefits of making this a special 
 supported case outweigh the additional language opacity.
>>> 
>>> I understand your goal, but that compiler magic can’t exist until there is 
>>> something to hook it into.  Tuples can’t conform to protocols right now, so 
>>> there is nothing that can be synthesized.
>>> 
>>> -Chris
>>> 
>>> 
 
 On Mon, Nov 20, 2017 at 8:42 PM, Chris Lattner > wrote:
 
> On Nov 20, 2017, at 5:39 PM, Kelvin Ma via swift-evolution 
> > wrote:
> 
> when SE-185 
> 
>  went through swift evolution, it was agreed that the next logical step 
> 

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Douglas Gregor via swift-evolution]

> On Nov 20, 2017, at 10:31 PM, Chris Lattner  wrote:
> 
> 
> 
>> On Nov 20, 2017, at 10:24 PM, David Hart > > wrote:
>> 
>> 
>> 
>> On 21 Nov 2017, at 03:17, Chris Lattner via swift-evolution 
>> > wrote:
>> 
>>> Yes, I agree, we need variadic generics before we can have tuples conform 
>>> :-(
>>> 
>>> At the end of the day, you want to be able to treat “(U, V, W)” as sugar 
>>> for Tuple just like we handle array sugar.  When that is possible, 
>>> Tuple is just a type like any other in the system (but we need variadics to 
>>> express it).
>> 
>> Eye-opening! Now I understand how important variadic generics are. Somebody 
>> should add that example to the Generics Manifesto.

It’s in there under “extensions of structural types”, here: 
https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#extensions-of-structural-types

with this example:

extension<...Elements : Equatable> (Elements...) : Equatable { // 
extending the tuple type "(Elements...)" to be Equatable
}

>> Questions:
>> 
>> • Doesn’t this simplification of the type system hoist Variadic Generics 
>> back up the list of priorities?
> 
> Not above conditional and recursive conformances.

Right, and we don’t have bandwidth to take on Another Major Generics Feature 
this year.

> 
>> • Would it be desirable to implement them before ABI stability to “remove” 
>> tuples from the ABI?

Tuples are structural types in the ABI (and type system), and should remain 
that way. So, I disagree with Chris’s suggestion that (U, V, W) will become 
Tuple. The most relevant comparison today is Optional, which is 
technically a nominal type but is treated as a special case basically 
everywhere in the compiler (and ABI) because it should have been a structural 
type. I expect optionals to become structural types in the future (the ABI is 
designed for that) and tuples to remain structural types.

>> • If not, is the current ABI already flexible enough to support them if they 
>> are implemented later on?
> 
> I am not the expert on this (Doug Gregor is), but I think we can add it later 
> in an ABI additive way.

Yes, we can add it to the ABI later.

- Doug

> 
> -Chris
> 
> 
> 
> 
> 
>>> Once you have that, then you could write conformances in general, as well 
>>> as conditional conformances that depend on (e.g.) all the element types 
>>> being equatable.
>>> 
>>> 
>>> We also need that to allow functions conform to protocols, because 
>>> functions aren’t "T1->T2” objects, the actual parameter list is an 
>>> inseparable part of the function type, and the parameter list needs 
>>> variadics.
>>> 
>>> -Chris
>>> 
 On Nov 20, 2017, at 6:10 PM, Slava Pestov > wrote:
 
 Ignoring synthesized conformances for a second, think about how you would 
 manually implement a conformance of a tuple type to a protocol. You would 
 need some way to statically “iterate” over all the component types of the 
 tuple — in fact this is the same as having variadic generics.
 
 If we had variadic generics, we could implement tuples conforming to 
 protocols, either by refactoring the compiler to allow conforming types to 
 be non-nominal, or by reworking things so that a tuple is a nominal type 
 with a single variadic generic parameter.
 
 Slava
 
> On Nov 20, 2017, at 9:06 PM, Tony Allevato via swift-evolution 
> > wrote:
> 
> This is something I've wanted to look at for a while. A few weeks ago I 
> pushed out https://github.com/apple/swift/pull/12598 
>  to extend the existing 
> synthesis to handle structs/enums when a field/payload has a tuple of 
> things that are Equatable/Hashable, and in that PR it was (rightly) 
> observed, as Chris just did, that making tuples conform to protocols 
> would be a more general solution that solves the same problem you want to 
> solve here.
> 
> I'd love to dig into this more, but last time I experimented with it I 
> got stuck on places where the protocol conformance machinery expects 
> NominalTypeDecls, and I wasn't sure where the right place to hoist that 
> logic up to was (since tuples don't have a corresponding Decl from what I 
> can tell). Any pointers?
> 
> On Mon, Nov 20, 2017 at 5:51 PM Chris Lattner via swift-evolution 
> > wrote:
> On Nov 20, 2017, at 5:48 PM, Kelvin Ma  > wrote:
>> the end goal here is to use tuples as a compatible currency type, to 
>> that end it makes sense for these three protocols to be handled as 
>> “compiler 

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Chris Lattner via swift-evolution]

> On Nov 21, 2017, at 9:06 AM, David Hart  wrote:
> 
>>> On 21 Nov 2017, at 03:17, Chris Lattner via swift-evolution 
>>> > wrote:
>>> 
 Yes, I agree, we need variadic generics before we can have tuples conform 
 :-(
 
 At the end of the day, you want to be able to treat “(U, V, W)” as sugar 
 for Tuple just like we handle array sugar.  When that is possible, 
 Tuple is just a type like any other in the system (but we need variadics 
 to express it).
>>> 
>>> Eye-opening! Now I understand how important variadic generics are. Somebody 
>>> should add that example to the Generics Manifesto. Questions:
>>> 
>>> • Doesn’t this simplification of the type system hoist Variadic Generics 
>>> back up the list of priorities?
>> 
>> Not above conditional and recursive conformances.
> 
> Correct. But recursive conformances are implemented and conditional 
> conformances are on the way. To rephrase my question: doesn't this 
> simplification of the type system hoist Variadic Generics to be the next big 
> priority after conditional conformances are finished?

I don’t know what the answer to your question is, nor do I know what the 
current list of priorities are.  :-)

-Chris

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

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[David Hart via swift-evolution]

> On 21 Nov 2017, at 07:31, Chris Lattner  wrote:
> 
> 
> 
>> On Nov 20, 2017, at 10:24 PM, David Hart > > wrote:
>> 
>> 
>> 
>> On 21 Nov 2017, at 03:17, Chris Lattner via swift-evolution 
>> > wrote:
>> 
>>> Yes, I agree, we need variadic generics before we can have tuples conform 
>>> :-(
>>> 
>>> At the end of the day, you want to be able to treat “(U, V, W)” as sugar 
>>> for Tuple just like we handle array sugar.  When that is possible, 
>>> Tuple is just a type like any other in the system (but we need variadics to 
>>> express it).
>> 
>> Eye-opening! Now I understand how important variadic generics are. Somebody 
>> should add that example to the Generics Manifesto. Questions:
>> 
>> • Doesn’t this simplification of the type system hoist Variadic Generics 
>> back up the list of priorities?
> 
> Not above conditional and recursive conformances.

Correct. But recursive conformances are implemented and conditional 
conformances are on the way. To rephrase my question: doesn't this 
simplification of the type system hoist Variadic Generics to be the next big 
priority after conditional conformances are finished?

>> • Would it be desirable to implement them before ABI stability to “remove” 
>> tuples from the ABI?
>> • If not, is the current ABI already flexible enough to support them if they 
>> are implemented later on?
> 
> I am not the expert on this (Doug Gregor is), but I think we can add it later 
> in an ABI additive way.
> 
> -Chris
> 
> 
> 
> 
> 
>>> Once you have that, then you could write conformances in general, as well 
>>> as conditional conformances that depend on (e.g.) all the element types 
>>> being equatable.
>>> 
>>> 
>>> We also need that to allow functions conform to protocols, because 
>>> functions aren’t "T1->T2” objects, the actual parameter list is an 
>>> inseparable part of the function type, and the parameter list needs 
>>> variadics.
>>> 
>>> -Chris
>>> 
 On Nov 20, 2017, at 6:10 PM, Slava Pestov > wrote:
 
 Ignoring synthesized conformances for a second, think about how you would 
 manually implement a conformance of a tuple type to a protocol. You would 
 need some way to statically “iterate” over all the component types of the 
 tuple — in fact this is the same as having variadic generics.
 
 If we had variadic generics, we could implement tuples conforming to 
 protocols, either by refactoring the compiler to allow conforming types to 
 be non-nominal, or by reworking things so that a tuple is a nominal type 
 with a single variadic generic parameter.
 
 Slava
 
> On Nov 20, 2017, at 9:06 PM, Tony Allevato via swift-evolution 
> > wrote:
> 
> This is something I've wanted to look at for a while. A few weeks ago I 
> pushed out https://github.com/apple/swift/pull/12598 
>  to extend the existing 
> synthesis to handle structs/enums when a field/payload has a tuple of 
> things that are Equatable/Hashable, and in that PR it was (rightly) 
> observed, as Chris just did, that making tuples conform to protocols 
> would be a more general solution that solves the same problem you want to 
> solve here.
> 
> I'd love to dig into this more, but last time I experimented with it I 
> got stuck on places where the protocol conformance machinery expects 
> NominalTypeDecls, and I wasn't sure where the right place to hoist that 
> logic up to was (since tuples don't have a corresponding Decl from what I 
> can tell). Any pointers?
> 
> On Mon, Nov 20, 2017 at 5:51 PM Chris Lattner via swift-evolution 
> > wrote:
> On Nov 20, 2017, at 5:48 PM, Kelvin Ma  > wrote:
>> the end goal here is to use tuples as a compatible currency type, to 
>> that end it makes sense for these three protocols to be handled as 
>> “compiler magic” and to disallow users from manually defining tuple 
>> conformances themselves. i’m not a fan of compiler magic, but Equatable, 
>> Hashable, and Comparable are special because they’re the basis for a lot 
>> of standard library functionality so i think the benefits of making this 
>> a special supported case outweigh the additional language opacity.
> 
> I understand your goal, but that compiler magic can’t exist until there 
> is something to hook it into.  Tuples can’t conform to protocols right 
> now, so there is nothing that can be synthesized.
> 
> -Chris
> 
> 
>> 
>> On Mon, Nov 20, 2017 at 8:42 PM, Chris Lattner > 

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Tony Allevato via swift-evolution]

On Tue, Nov 21, 2017 at 8:43 AM Howard Lovatt via swift-evolution <
swift-evolution@swift.org> wrote:

> In Scala they just define Tuple1, Tuple2, ... up to 22 (I think).
> Eliminates the need for variadic generics and works fine in practice in
> Scala.
>
> In Swift this approach is possibly unacceptable, since having to write:
>
> extension Tuple1 ...
> extension Tuple2 ...
> ...
> extension Tuple22 ...
>
> Is a real pain.
>
> However if we added variadic generics, Tuple, then we would also
> need a tuple to become a Collection (or some minimal subset of), e.g.:
>
> extension Tuple: Equatable where T: Equatable {
> static func == (lhs: Tuple, rhs: Tuple) -> Bool {
> guard lhs.count == rhs.count else {
> return false
> }
> for i in 0 ..< lhs.count {
> guard lhs[i] == rhs[i] else {
> return false
> }
> }
> return true
> }
> }
>
>
It's a bit more complex than that—saying `where T: Equatable` feels off
because `T` here isn't a single type. A syntax like `T...: Equatable` to
mean "all arguments in the parameter pack conform to Equatable" might be
clearer.

Adding Collection conformance is also problematic because tuples can be
heterogeneous. If you have Tuple, what's the type
of lhs[i]? It depends on i, which isn't going to work.

We'd probably need some syntax for destructuring tuples into a "first"
element and "rest" tuple of arity N–1 so that equality (and other
operations) could be implemented recursively, statically at compile time.

Of course, all of this gets dangerously into the realm of C++ template
metaprogramming horrors. :)  Hopefully we can come up with less obtuse
solutions/syntax for Swift.



> Note how the tuple is treated like a collection. The compiler magic would
> be to make a Tuple a collection, which is more ‘magic’ than ‘magically’
> adding Hashable :).
>
> Despite the profusion of magic, variadic generics and Tuple collection
> additions are my favourite option.
>
>
> -- Howard.
>
> On 21 Nov 2017, at 1:17 pm, Chris Lattner via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Yes, I agree, we need variadic generics before we can have tuples conform
> :-(
>
> At the end of the day, you want to be able to treat “(U, V, W)” as sugar
> for Tuple just like we handle array sugar.  When that is possible,
> Tuple is just a type like any other in the system (but we need variadics to
> express it).
>
> Once you have that, then you could write conformances in general, as well
> as conditional conformances that depend on (e.g.) all the element types
> being equatable.
>
>
> We also need that to allow functions conform to protocols, because
> functions aren’t "T1->T2” objects, the actual parameter list is an
> inseparable part of the function type, and the parameter list needs
> variadics.
>
> -Chris
>
> On Nov 20, 2017, at 6:10 PM, Slava Pestov  wrote:
>
> Ignoring synthesized conformances for a second, think about how you would
> manually implement a conformance of a tuple type to a protocol. You would
> need some way to statically “iterate” over all the component types of the
> tuple — in fact this is the same as having variadic generics.
>
> If we had variadic generics, we could implement tuples conforming to
> protocols, either by refactoring the compiler to allow conforming types to
> be non-nominal, or by reworking things so that a tuple is a nominal type
> with a single variadic generic parameter.
>
> Slava
>
> On Nov 20, 2017, at 9:06 PM, Tony Allevato via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> This is something I've wanted to look at for a while. A few weeks ago I
> pushed out https://github.com/apple/swift/pull/12598 to extend the
> existing synthesis to handle structs/enums when a field/payload has a tuple
> of things that are Equatable/Hashable, and in that PR it was (rightly)
> observed, as Chris just did, that making tuples conform to protocols would
> be a more general solution that solves the same problem you want to solve
> here.
>
> I'd love to dig into this more, but last time I experimented with it I got
> stuck on places where the protocol conformance machinery expects
> NominalTypeDecls, and I wasn't sure where the right place to hoist that
> logic up to was (since tuples don't have a corresponding Decl from what I
> can tell). Any pointers?
>
> On Mon, Nov 20, 2017 at 5:51 PM Chris Lattner via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> On Nov 20, 2017, at 5:48 PM, Kelvin Ma  wrote:
>>
>> the end goal here is to use tuples as a compatible currency type, to that
>> end it makes sense for these three protocols to be handled as “compiler
>> magic” and to disallow users from manually defining tuple conformances
>> themselves. i’m not a fan of compiler magic, but Equatable, Hashable, and
>> 

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Howard Lovatt via swift-evolution]

In Scala they just define Tuple1, Tuple2, ... up to 22 (I think). 
Eliminates the need for variadic generics and works fine in practice in Scala. 

In Swift this approach is possibly unacceptable, since having to write:

extension Tuple1 ...
extension Tuple2 ...
...
extension Tuple22 ...

Is a real pain. 

However if we added variadic generics, Tuple, then we would also need a 
tuple to become a Collection (or some minimal subset of), e.g.:

extension Tuple: Equatable where T: Equatable {
static func == (lhs: Tuple, rhs: Tuple) -> Bool {
guard lhs.count == rhs.count else {
return false
}
for i in 0 ..< lhs.count {
guard lhs[i] == rhs[i] else {
return false
}
}
return true
}
}

Note how the tuple is treated like a collection. The compiler magic would be to 
make a Tuple a collection, which is more ‘magic’ than ‘magically’ adding 
Hashable :).

Despite the profusion of magic, variadic generics and Tuple collection 
additions are my favourite option. 

-- Howard. 

> On 21 Nov 2017, at 1:17 pm, Chris Lattner via swift-evolution 
>  wrote:
> 
> Yes, I agree, we need variadic generics before we can have tuples conform :-(
> 
> At the end of the day, you want to be able to treat “(U, V, W)” as sugar for 
> Tuple just like we handle array sugar.  When that is possible, Tuple 
> is just a type like any other in the system (but we need variadics to express 
> it).
> 
> Once you have that, then you could write conformances in general, as well as 
> conditional conformances that depend on (e.g.) all the element types being 
> equatable.
> 
> 
> We also need that to allow functions conform to protocols, because functions 
> aren’t "T1->T2” objects, the actual parameter list is an inseparable part of 
> the function type, and the parameter list needs variadics.
> 
> -Chris
> 
>> On Nov 20, 2017, at 6:10 PM, Slava Pestov  wrote:
>> 
>> Ignoring synthesized conformances for a second, think about how you would 
>> manually implement a conformance of a tuple type to a protocol. You would 
>> need some way to statically “iterate” over all the component types of the 
>> tuple — in fact this is the same as having variadic generics.
>> 
>> If we had variadic generics, we could implement tuples conforming to 
>> protocols, either by refactoring the compiler to allow conforming types to 
>> be non-nominal, or by reworking things so that a tuple is a nominal type 
>> with a single variadic generic parameter.
>> 
>> Slava
>> 
>>> On Nov 20, 2017, at 9:06 PM, Tony Allevato via swift-evolution 
>>>  wrote:
>>> 
>>> This is something I've wanted to look at for a while. A few weeks ago I 
>>> pushed out https://github.com/apple/swift/pull/12598 to extend the existing 
>>> synthesis to handle structs/enums when a field/payload has a tuple of 
>>> things that are Equatable/Hashable, and in that PR it was (rightly) 
>>> observed, as Chris just did, that making tuples conform to protocols would 
>>> be a more general solution that solves the same problem you want to solve 
>>> here.
>>> 
>>> I'd love to dig into this more, but last time I experimented with it I got 
>>> stuck on places where the protocol conformance machinery expects 
>>> NominalTypeDecls, and I wasn't sure where the right place to hoist that 
>>> logic up to was (since tuples don't have a corresponding Decl from what I 
>>> can tell). Any pointers?
>>> 
 On Mon, Nov 20, 2017 at 5:51 PM Chris Lattner via swift-evolution 
  wrote:
> On Nov 20, 2017, at 5:48 PM, Kelvin Ma  wrote:
> the end goal here is to use tuples as a compatible currency type, to that 
> end it makes sense for these three protocols to be handled as “compiler 
> magic” and to disallow users from manually defining tuple conformances 
> themselves. i’m not a fan of compiler magic, but Equatable, Hashable, and 
> Comparable are special because they’re the basis for a lot of standard 
> library functionality so i think the benefits of making this a special 
> supported case outweigh the additional language opacity.
 
 I understand your goal, but that compiler magic can’t exist until there is 
 something to hook it into.  Tuples can’t conform to protocols right now, 
 so there is nothing that can be synthesized.
 
 -Chris
 
 
> 
>> On Mon, Nov 20, 2017 at 8:42 PM, Chris Lattner  
>> wrote:
>> 
>>> On Nov 20, 2017, at 5:39 PM, Kelvin Ma via swift-evolution 
>>>  wrote:
>>> 
>>> when SE-185 went through swift evolution, it was agreed that the next 
>>> logical step is synthesizing these conformances for tuple types, though 
>>> it was left out of the 

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Dave DeLong via swift-evolution]

> On Nov 20, 2017, at 11:32 PM, Kelvin Ma via swift-evolution 
>  wrote:
> 
> a good idea on paper, a disastrous one in practice. What happens if every 
> geometry library declares their own Point type?

we’d end up with the same situation we have now where everyone declares their 
own Result type.

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

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Thorsten Seitz via swift-evolution]

> Am 21.11.2017 um 07:32 schrieb Kelvin Ma :
> 
> a good idea on paper, a disastrous one in practice. What happens if every 
> geometry library declares their own Point type?

Well, if I really had the need to use several geometry libraries at once I 
would have to convert, of course. But I prefer that to the loss of type safety 
where I could confuse points, vectors and probably more, like colors or 
whatever else ends up as a tuple...

-Thorsten

> 
> On Tue, Nov 21, 2017 at 1:15 AM, Thorsten Seitz  wrote:
>> 
>> 
>>> Am 21.11.2017 um 02:39 schrieb Kelvin Ma via swift-evolution 
>>> :
>>> 
>>> when SE-185 went through swift evolution, it was agreed that the next 
>>> logical step is synthesizing these conformances for tuple types, though it 
>>> was left out of the original proposal to avoid mission creep. I think now 
>>> is the time to start thinking about this. i’m also tacking on Comparable to 
>>> the other two protocols because there is precedent in the language from 
>>> SE-15 that tuple comparison is something that makes sense to write.
>>> 
>>> EHC conformance is even more important for tuples than it is for structs 
>>> because tuples effectively have no workaround whereas in structs, you could 
>>> just manually implement the conformance. this is especially relevant in 
>>> graphics and scientific contexts where tuples are used to represent color 
>>> values and points in 2D or 3D space. today you still can’t do things like 
>>> 
>>> let lattice = Dictionary<(Int, Int, Int), AssociatedValue>() .
>>> 
>>> the commonly suggested “workaround”, which is to “upgrade” the tuple to a 
>>> struct is problematic for two reasons:
>>> 
>>> 1. it defeats the purpose of having tuples in the language
>>> 
>>> 2. tuples are a logical currency type for commonly used types like points 
>>> and vectors. If every library defined its own custom point/vector types we 
>>> would soon (already?) have a nightmare situation where no geometry/graphics 
>>> library would be compatible with any other geometry/graphics library, at 
>>> least not without a lot of annoying, let alone wasteful swizzling and 
>>> manual conversion routines in the main application.
>> 
>> Actually I don't think that tuples should be used for points and vectors at 
>> all, because I prefer to differentiate these two concepts which requires 
>> nominal types, e.g.
>> 
>> struct Point {
>> func distance(to point: Point) -> Vector
>> func offsetBy(_ offset: Vector) -> Point
>> }
>> 
>> Notwithstanding this disagreement I too think that EHC conformance for 
>> tuples would be useful. 
>> 
>> -Thorsten
>> 
>> 
>>> ___
>>> 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] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Kelvin Ma via swift-evolution]

a good idea on paper, a disastrous one in practice. What happens if every
geometry library declares their own Point type?

On Tue, Nov 21, 2017 at 1:15 AM, Thorsten Seitz  wrote:

>
>
> Am 21.11.2017 um 02:39 schrieb Kelvin Ma via swift-evolution <
> swift-evolution@swift.org>:
>
> when SE-185
> 
> went through swift evolution, it was agreed that the next logical step
>  is
> synthesizing these conformances for tuple types, though it was left out of
> the original proposal to avoid mission creep. I think now is the time to
> start thinking about this. i’m also tacking on Comparable to the other
> two protocols because there is precedent in the language from SE-15
> 
> that tuple comparison is something that makes sense to write.
>
> EHC conformance is even more important for tuples than it is for structs
> because tuples effectively have no workaround whereas in structs, you could
> just manually implement the conformance. this is especially relevant in
> graphics and scientific contexts where tuples are used to represent color
> values and points in 2D or 3D space. today you still can’t do things like
>
> let lattice = Dictionary<(Int, Int, Int), AssociatedValue>() .
>
> the commonly suggested “workaround”, which is to “upgrade” the tuple to a
> struct is problematic for two reasons:
>
> 1. it defeats the purpose of having tuples in the language
>
> 2. tuples are a logical currency type for commonly used types like points
> and vectors. If every library defined its own custom point/vector types we
> would soon (already?) have a nightmare situation where no geometry/graphics
> library would be compatible with any other geometry/graphics library, at
> least not without a lot of annoying, let alone wasteful swizzling and
> manual conversion routines in the main application.
>
>
> Actually I don't think that tuples should be used for points and vectors
> at all, because I prefer to differentiate these two concepts which requires
> nominal types, e.g.
>
> struct Point {
> func distance(to point: Point) -> Vector
> func offsetBy(_ offset: Vector) -> Point
> }
>
> Notwithstanding this disagreement I too think that EHC conformance for
> tuples would be useful.
>
> -Thorsten
>
>
> ___
> 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] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Chris Lattner via swift-evolution]

> On Nov 20, 2017, at 10:24 PM, David Hart  wrote:
> 
> 
> 
> On 21 Nov 2017, at 03:17, Chris Lattner via swift-evolution 
> > wrote:
> 
>> Yes, I agree, we need variadic generics before we can have tuples conform :-(
>> 
>> At the end of the day, you want to be able to treat “(U, V, W)” as sugar for 
>> Tuple just like we handle array sugar.  When that is possible, Tuple 
>> is just a type like any other in the system (but we need variadics to 
>> express it).
> 
> Eye-opening! Now I understand how important variadic generics are. Somebody 
> should add that example to the Generics Manifesto. Questions:
> 
> • Doesn’t this simplification of the type system hoist Variadic Generics back 
> up the list of priorities?

Not above conditional and recursive conformances.

> • Would it be desirable to implement them before ABI stability to “remove” 
> tuples from the ABI?
> • If not, is the current ABI already flexible enough to support them if they 
> are implemented later on?

I am not the expert on this (Doug Gregor is), but I think we can add it later 
in an ABI additive way.

-Chris





>> Once you have that, then you could write conformances in general, as well as 
>> conditional conformances that depend on (e.g.) all the element types being 
>> equatable.
>> 
>> 
>> We also need that to allow functions conform to protocols, because functions 
>> aren’t "T1->T2” objects, the actual parameter list is an inseparable part of 
>> the function type, and the parameter list needs variadics.
>> 
>> -Chris
>> 
>>> On Nov 20, 2017, at 6:10 PM, Slava Pestov >> > wrote:
>>> 
>>> Ignoring synthesized conformances for a second, think about how you would 
>>> manually implement a conformance of a tuple type to a protocol. You would 
>>> need some way to statically “iterate” over all the component types of the 
>>> tuple — in fact this is the same as having variadic generics.
>>> 
>>> If we had variadic generics, we could implement tuples conforming to 
>>> protocols, either by refactoring the compiler to allow conforming types to 
>>> be non-nominal, or by reworking things so that a tuple is a nominal type 
>>> with a single variadic generic parameter.
>>> 
>>> Slava
>>> 
 On Nov 20, 2017, at 9:06 PM, Tony Allevato via swift-evolution 
 > wrote:
 
 This is something I've wanted to look at for a while. A few weeks ago I 
 pushed out https://github.com/apple/swift/pull/12598 
  to extend the existing 
 synthesis to handle structs/enums when a field/payload has a tuple of 
 things that are Equatable/Hashable, and in that PR it was (rightly) 
 observed, as Chris just did, that making tuples conform to protocols would 
 be a more general solution that solves the same problem you want to solve 
 here.
 
 I'd love to dig into this more, but last time I experimented with it I got 
 stuck on places where the protocol conformance machinery expects 
 NominalTypeDecls, and I wasn't sure where the right place to hoist that 
 logic up to was (since tuples don't have a corresponding Decl from what I 
 can tell). Any pointers?
 
 On Mon, Nov 20, 2017 at 5:51 PM Chris Lattner via swift-evolution 
 > wrote:
 On Nov 20, 2017, at 5:48 PM, Kelvin Ma > wrote:
> the end goal here is to use tuples as a compatible currency type, to that 
> end it makes sense for these three protocols to be handled as “compiler 
> magic” and to disallow users from manually defining tuple conformances 
> themselves. i’m not a fan of compiler magic, but Equatable, Hashable, and 
> Comparable are special because they’re the basis for a lot of standard 
> library functionality so i think the benefits of making this a special 
> supported case outweigh the additional language opacity.
 
 I understand your goal, but that compiler magic can’t exist until there is 
 something to hook it into.  Tuples can’t conform to protocols right now, 
 so there is nothing that can be synthesized.
 
 -Chris
 
 
> 
> On Mon, Nov 20, 2017 at 8:42 PM, Chris Lattner  > wrote:
> 
>> On Nov 20, 2017, at 5:39 PM, Kelvin Ma via swift-evolution 
>> > wrote:
>> 
>> when SE-185 
>> 
>>  went through swift evolution, it was agreed that the next logical step 
>>  
>> is 

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[David Hart via swift-evolution]

> On 21 Nov 2017, at 03:17, Chris Lattner via swift-evolution 
>  wrote:
> 
> Yes, I agree, we need variadic generics before we can have tuples conform :-(
> 
> At the end of the day, you want to be able to treat “(U, V, W)” as sugar for 
> Tuple just like we handle array sugar.  When that is possible, Tuple 
> is just a type like any other in the system (but we need variadics to express 
> it).

Eye-opening! Now I understand how important variadic generics are. Somebody 
should add that example to the Generics Manifesto. Questions:

• Doesn’t this simplification of the type system hoist Variadic Generics back 
up the list of priorities?
• Would it be desirable to implement them before ABI stability to “remove” 
tuples from the ABI?
• If not, is the current ABI already flexible enough to support them if they 
are implemented later on?

> Once you have that, then you could write conformances in general, as well as 
> conditional conformances that depend on (e.g.) all the element types being 
> equatable.
> 
> 
> We also need that to allow functions conform to protocols, because functions 
> aren’t "T1->T2” objects, the actual parameter list is an inseparable part of 
> the function type, and the parameter list needs variadics.
> 
> -Chris
> 
>> On Nov 20, 2017, at 6:10 PM, Slava Pestov  wrote:
>> 
>> Ignoring synthesized conformances for a second, think about how you would 
>> manually implement a conformance of a tuple type to a protocol. You would 
>> need some way to statically “iterate” over all the component types of the 
>> tuple — in fact this is the same as having variadic generics.
>> 
>> If we had variadic generics, we could implement tuples conforming to 
>> protocols, either by refactoring the compiler to allow conforming types to 
>> be non-nominal, or by reworking things so that a tuple is a nominal type 
>> with a single variadic generic parameter.
>> 
>> Slava
>> 
>>> On Nov 20, 2017, at 9:06 PM, Tony Allevato via swift-evolution 
>>>  wrote:
>>> 
>>> This is something I've wanted to look at for a while. A few weeks ago I 
>>> pushed out https://github.com/apple/swift/pull/12598 to extend the existing 
>>> synthesis to handle structs/enums when a field/payload has a tuple of 
>>> things that are Equatable/Hashable, and in that PR it was (rightly) 
>>> observed, as Chris just did, that making tuples conform to protocols would 
>>> be a more general solution that solves the same problem you want to solve 
>>> here.
>>> 
>>> I'd love to dig into this more, but last time I experimented with it I got 
>>> stuck on places where the protocol conformance machinery expects 
>>> NominalTypeDecls, and I wasn't sure where the right place to hoist that 
>>> logic up to was (since tuples don't have a corresponding Decl from what I 
>>> can tell). Any pointers?
>>> 
 On Mon, Nov 20, 2017 at 5:51 PM Chris Lattner via swift-evolution 
  wrote:
> On Nov 20, 2017, at 5:48 PM, Kelvin Ma  wrote:
> the end goal here is to use tuples as a compatible currency type, to that 
> end it makes sense for these three protocols to be handled as “compiler 
> magic” and to disallow users from manually defining tuple conformances 
> themselves. i’m not a fan of compiler magic, but Equatable, Hashable, and 
> Comparable are special because they’re the basis for a lot of standard 
> library functionality so i think the benefits of making this a special 
> supported case outweigh the additional language opacity.
 
 I understand your goal, but that compiler magic can’t exist until there is 
 something to hook it into.  Tuples can’t conform to protocols right now, 
 so there is nothing that can be synthesized.
 
 -Chris
 
 
> 
>> On Mon, Nov 20, 2017 at 8:42 PM, Chris Lattner  
>> wrote:
>> 
>>> On Nov 20, 2017, at 5:39 PM, Kelvin Ma via swift-evolution 
>>>  wrote:
>>> 
>>> when SE-185 went through swift evolution, it was agreed that the next 
>>> logical step is synthesizing these conformances for tuple types, though 
>>> it was left out of the original proposal to avoid mission creep. I 
>>> think now is the time to start thinking about this. i’m also tacking on 
>>> Comparable to the other two protocols because there is precedent in the 
>>> language from SE-15 that tuple comparison is something that makes sense 
>>> to write.
>>> 
>>> EHC conformance is even more important for tuples than it is for 
>>> structs because tuples effectively have no workaround whereas in 
>>> structs, you could just manually implement the conformance. 
>> 
>> In my opinion, you’re approaching this from the wrong direction.  The 
>> fundamental problem here is that tuples can’t conform to a protocol.  If 
>> they 

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Thorsten Seitz via swift-evolution]

> Am 21.11.2017 um 02:39 schrieb Kelvin Ma via swift-evolution 
> :
> 
> when SE-185 went through swift evolution, it was agreed that the next logical 
> step is synthesizing these conformances for tuple types, though it was left 
> out of the original proposal to avoid mission creep. I think now is the time 
> to start thinking about this. i’m also tacking on Comparable to the other two 
> protocols because there is precedent in the language from SE-15 that tuple 
> comparison is something that makes sense to write.
> 
> EHC conformance is even more important for tuples than it is for structs 
> because tuples effectively have no workaround whereas in structs, you could 
> just manually implement the conformance. this is especially relevant in 
> graphics and scientific contexts where tuples are used to represent color 
> values and points in 2D or 3D space. today you still can’t do things like 
> 
> let lattice = Dictionary<(Int, Int, Int), AssociatedValue>() .
> 
> the commonly suggested “workaround”, which is to “upgrade” the tuple to a 
> struct is problematic for two reasons:
> 
> 1. it defeats the purpose of having tuples in the language
> 
> 2. tuples are a logical currency type for commonly used types like points and 
> vectors. If every library defined its own custom point/vector types we would 
> soon (already?) have a nightmare situation where no geometry/graphics library 
> would be compatible with any other geometry/graphics library, at least not 
> without a lot of annoying, let alone wasteful swizzling and manual conversion 
> routines in the main application.

Actually I don't think that tuples should be used for points and vectors at 
all, because I prefer to differentiate these two concepts which requires 
nominal types, e.g.

struct Point {
func distance(to point: Point) -> Vector
func offsetBy(_ offset: Vector) -> Point
}

Notwithstanding this disagreement I too think that EHC conformance for tuples 
would be useful. 

-Thorsten


> ___
> 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] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Chris Lattner via swift-evolution]

On Nov 20, 2017, at 6:31 PM, Tony Allevato  wrote:
> 
> So (borrowing C++-ish notation), a function of type `(Args...) -> Result` 
> would become sugar for something like `Function`? That 
> certainly makes sense.

Yep

> How would throw-ness be handled—would we need ThrowingFunction and Function, 
> with the ability to coerce Function -> ThrowingFunction? (Async might pose 
> similar issues?)

Right, there are several ways we could express that which would have to be 
designed.  There are other questions as well: e.g. how do we represent inout?

-Chris


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

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Chris Lattner via swift-evolution]

On Nov 20, 2017, at 6:30 PM, Kelvin Ma via swift-evolution 
 wrote:
> 
> can we go the route of SE-15 and just synthesize up to some sensible n = 7 or 
> whatever. i feel like this list has a habit of going “but it would be a lot 
> better to add X if we just wait until Y is a thing first” ignoring that Y 
> will probably not be a thing for the forseeable future and we really need X 
> right now

Sure, you can generate implementations of == or hashing functions, but that 
won’t let you use them as the key to a dictionary.  For that, you need actual 
conformance.

-Chris


> 
> On Mon, Nov 20, 2017 at 9:10 PM, Slava Pestov via swift-evolution 
> > wrote:
> Ignoring synthesized conformances for a second, think about how you would 
> manually implement a conformance of a tuple type to a protocol. You would 
> need some way to statically “iterate” over all the component types of the 
> tuple — in fact this is the same as having variadic generics.
> 
> If we had variadic generics, we could implement tuples conforming to 
> protocols, either by refactoring the compiler to allow conforming types to be 
> non-nominal, or by reworking things so that a tuple is a nominal type with a 
> single variadic generic parameter.
> 
> Slava
> 
> 
>> On Nov 20, 2017, at 9:06 PM, Tony Allevato via swift-evolution 
>> > wrote:
>> 
>> This is something I've wanted to look at for a while. A few weeks ago I 
>> pushed out https://github.com/apple/swift/pull/12598 
>>  to extend the existing synthesis 
>> to handle structs/enums when a field/payload has a tuple of things that are 
>> Equatable/Hashable, and in that PR it was (rightly) observed, as Chris just 
>> did, that making tuples conform to protocols would be a more general 
>> solution that solves the same problem you want to solve here.
>> 
>> I'd love to dig into this more, but last time I experimented with it I got 
>> stuck on places where the protocol conformance machinery expects 
>> NominalTypeDecls, and I wasn't sure where the right place to hoist that 
>> logic up to was (since tuples don't have a corresponding Decl from what I 
>> can tell). Any pointers?
>> 
>> On Mon, Nov 20, 2017 at 5:51 PM Chris Lattner via swift-evolution 
>> > wrote:
>> On Nov 20, 2017, at 5:48 PM, Kelvin Ma > > wrote:
>>> the end goal here is to use tuples as a compatible currency type, to that 
>>> end it makes sense for these three protocols to be handled as “compiler 
>>> magic” and to disallow users from manually defining tuple conformances 
>>> themselves. i’m not a fan of compiler magic, but Equatable, Hashable, and 
>>> Comparable are special because they’re the basis for a lot of standard 
>>> library functionality so i think the benefits of making this a special 
>>> supported case outweigh the additional language opacity.
>> 
>> I understand your goal, but that compiler magic can’t exist until there is 
>> something to hook it into.  Tuples can’t conform to protocols right now, so 
>> there is nothing that can be synthesized.
>> 
>> -Chris
>> 
>> 
>>> 
>>> On Mon, Nov 20, 2017 at 8:42 PM, Chris Lattner >> > wrote:
>>> 
 On Nov 20, 2017, at 5:39 PM, Kelvin Ma via swift-evolution 
 > wrote:
 
 when SE-185 
 
  went through swift evolution, it was agreed that the next logical step 
  is 
 synthesizing these conformances for tuple types, though it was left out of 
 the original proposal to avoid mission creep. I think now is the time to 
 start thinking about this. i’m also tacking on Comparable to the other two 
 protocols because there is precedent in the language from SE-15 
 
  that tuple comparison is something that makes sense to write.
 
 EHC conformance is even more important for tuples than it is for structs 
 because tuples effectively have no workaround whereas in structs, you 
 could just manually implement the conformance. 
>>> 
>>> In my opinion, you’re approaching this from the wrong direction.  The 
>>> fundamental problem here is that tuples can’t conform to a protocol.  If 
>>> they could, synthesizing these conformances would be straight-forward.
>>> 
>>> If you’re interested in pushing this forward, the discussion is “how do 
>>> non-nominal types like tuples and functions conform to protocols”?
>>> 
>>> -Chris
>>> 
>>> 

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Tony Allevato via swift-evolution]

So (borrowing C++-ish notation), a function of type `(Args...) -> Result`
would become sugar for something like `Function`? That
certainly makes sense.

How would throw-ness be handled—would we need ThrowingFunction and
Function, with the ability to coerce Function -> ThrowingFunction? (Async
might pose similar issues?)


On Mon, Nov 20, 2017 at 6:17 PM Chris Lattner  wrote:

> Yes, I agree, we need variadic generics before we can have tuples conform
> :-(
>
> At the end of the day, you want to be able to treat “(U, V, W)” as sugar
> for Tuple just like we handle array sugar.  When that is possible,
> Tuple is just a type like any other in the system (but we need variadics to
> express it).
>
> Once you have that, then you could write conformances in general, as well
> as conditional conformances that depend on (e.g.) all the element types
> being equatable.
>
>
> We also need that to allow functions conform to protocols, because
> functions aren’t "T1->T2” objects, the actual parameter list is an
> inseparable part of the function type, and the parameter list needs
> variadics.
>
> -Chris
>
> On Nov 20, 2017, at 6:10 PM, Slava Pestov  wrote:
>
> Ignoring synthesized conformances for a second, think about how you would
> manually implement a conformance of a tuple type to a protocol. You would
> need some way to statically “iterate” over all the component types of the
> tuple — in fact this is the same as having variadic generics.
>
> If we had variadic generics, we could implement tuples conforming to
> protocols, either by refactoring the compiler to allow conforming types to
> be non-nominal, or by reworking things so that a tuple is a nominal type
> with a single variadic generic parameter.
>
> Slava
>
> On Nov 20, 2017, at 9:06 PM, Tony Allevato via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> This is something I've wanted to look at for a while. A few weeks ago I
> pushed out https://github.com/apple/swift/pull/12598 to extend the
> existing synthesis to handle structs/enums when a field/payload has a tuple
> of things that are Equatable/Hashable, and in that PR it was (rightly)
> observed, as Chris just did, that making tuples conform to protocols would
> be a more general solution that solves the same problem you want to solve
> here.
>
> I'd love to dig into this more, but last time I experimented with it I got
> stuck on places where the protocol conformance machinery expects
> NominalTypeDecls, and I wasn't sure where the right place to hoist that
> logic up to was (since tuples don't have a corresponding Decl from what I
> can tell). Any pointers?
>
> On Mon, Nov 20, 2017 at 5:51 PM Chris Lattner via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> On Nov 20, 2017, at 5:48 PM, Kelvin Ma  wrote:
>>
>> the end goal here is to use tuples as a compatible currency type, to that
>> end it makes sense for these three protocols to be handled as “compiler
>> magic” and to disallow users from manually defining tuple conformances
>> themselves. i’m not a fan of compiler magic, but Equatable, Hashable, and
>> Comparable are special because they’re the basis for a lot of standard
>> library functionality so i think the benefits of making this a special
>> supported case outweigh the additional language opacity.
>>
>>
>> I understand your goal, but that compiler magic can’t exist until there
>> is something to hook it into.  Tuples can’t conform to protocols right now,
>> so there is nothing that can be synthesized.
>>
>> -Chris
>>
>>
>>
>> On Mon, Nov 20, 2017 at 8:42 PM, Chris Lattner 
>> wrote:
>>
>>>
>>> On Nov 20, 2017, at 5:39 PM, Kelvin Ma via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
>>> when SE-185
>>> 
>>> went through swift evolution, it was agreed that the next logical step
>>> 
>>> is synthesizing these conformances for tuple types, though it was left out
>>> of the original proposal to avoid mission creep. I think now is the time to
>>> start thinking about this. i’m also tacking on Comparable to the other
>>> two protocols because there is precedent in the language from SE-15
>>> 
>>> that tuple comparison is something that makes sense to write.
>>>
>>> EHC conformance is even more important for tuples than it is for structs
>>> because tuples effectively have no workaround whereas in structs, you could
>>> just manually implement the conformance.
>>>
>>>
>>> In my opinion, you’re approaching this from the wrong direction.  The
>>> fundamental problem here is that tuples can’t conform to a protocol.  If
>>> they could, synthesizing these conformances would be straight-forward.
>>>

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Kelvin Ma via swift-evolution]

can we go the route of SE-15 and just synthesize up to some sensible n = 7
or whatever. i feel like this list has a habit of going “but it would be a
lot better to add X if we just wait until Y is a thing first” ignoring that
Y will probably not be a thing for the forseeable future and we really need
X right now

On Mon, Nov 20, 2017 at 9:10 PM, Slava Pestov via swift-evolution <
swift-evolution@swift.org> wrote:

> Ignoring synthesized conformances for a second, think about how you would
> manually implement a conformance of a tuple type to a protocol. You would
> need some way to statically “iterate” over all the component types of the
> tuple — in fact this is the same as having variadic generics.
>
> If we had variadic generics, we could implement tuples conforming to
> protocols, either by refactoring the compiler to allow conforming types to
> be non-nominal, or by reworking things so that a tuple is a nominal type
> with a single variadic generic parameter.
>
> Slava
>
>
> On Nov 20, 2017, at 9:06 PM, Tony Allevato via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> This is something I've wanted to look at for a while. A few weeks ago I
> pushed out https://github.com/apple/swift/pull/12598 to extend the
> existing synthesis to handle structs/enums when a field/payload has a tuple
> of things that are Equatable/Hashable, and in that PR it was (rightly)
> observed, as Chris just did, that making tuples conform to protocols would
> be a more general solution that solves the same problem you want to solve
> here.
>
> I'd love to dig into this more, but last time I experimented with it I got
> stuck on places where the protocol conformance machinery expects
> NominalTypeDecls, and I wasn't sure where the right place to hoist that
> logic up to was (since tuples don't have a corresponding Decl from what I
> can tell). Any pointers?
>
> On Mon, Nov 20, 2017 at 5:51 PM Chris Lattner via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> On Nov 20, 2017, at 5:48 PM, Kelvin Ma  wrote:
>>
>> the end goal here is to use tuples as a compatible currency type, to that
>> end it makes sense for these three protocols to be handled as “compiler
>> magic” and to disallow users from manually defining tuple conformances
>> themselves. i’m not a fan of compiler magic, but Equatable, Hashable, and
>> Comparable are special because they’re the basis for a lot of standard
>> library functionality so i think the benefits of making this a special
>> supported case outweigh the additional language opacity.
>>
>>
>> I understand your goal, but that compiler magic can’t exist until there
>> is something to hook it into.  Tuples can’t conform to protocols right now,
>> so there is nothing that can be synthesized.
>>
>> -Chris
>>
>>
>>
>> On Mon, Nov 20, 2017 at 8:42 PM, Chris Lattner 
>> wrote:
>>
>>>
>>> On Nov 20, 2017, at 5:39 PM, Kelvin Ma via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
>>> when SE-185
>>> 
>>> went through swift evolution, it was agreed that the next logical step
>>> 
>>> is synthesizing these conformances for tuple types, though it was left out
>>> of the original proposal to avoid mission creep. I think now is the time to
>>> start thinking about this. i’m also tacking on Comparable to the other
>>> two protocols because there is precedent in the language from SE-15
>>> 
>>> that tuple comparison is something that makes sense to write.
>>>
>>> EHC conformance is even more important for tuples than it is for structs
>>> because tuples effectively have no workaround whereas in structs, you could
>>> just manually implement the conformance.
>>>
>>>
>>> In my opinion, you’re approaching this from the wrong direction.  The
>>> fundamental problem here is that tuples can’t conform to a protocol.  If
>>> they could, synthesizing these conformances would be straight-forward.
>>>
>>> If you’re interested in pushing this forward, the discussion is “how do
>>> non-nominal types like tuples and functions conform to protocols”?
>>>
>>> -Chris
>>>
>>>
>>>
>>>
>>>
>> ___
>> 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
>
>
___
swift-evolution mailing list
swift-evolution@swift.org

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Chris Lattner via swift-evolution]

Yes, I agree, we need variadic generics before we can have tuples conform :-(

At the end of the day, you want to be able to treat “(U, V, W)” as sugar for 
Tuple just like we handle array sugar.  When that is possible, Tuple is 
just a type like any other in the system (but we need variadics to express it).

Once you have that, then you could write conformances in general, as well as 
conditional conformances that depend on (e.g.) all the element types being 
equatable.


We also need that to allow functions conform to protocols, because functions 
aren’t "T1->T2” objects, the actual parameter list is an inseparable part of 
the function type, and the parameter list needs variadics.

-Chris

> On Nov 20, 2017, at 6:10 PM, Slava Pestov  wrote:
> 
> Ignoring synthesized conformances for a second, think about how you would 
> manually implement a conformance of a tuple type to a protocol. You would 
> need some way to statically “iterate” over all the component types of the 
> tuple — in fact this is the same as having variadic generics.
> 
> If we had variadic generics, we could implement tuples conforming to 
> protocols, either by refactoring the compiler to allow conforming types to be 
> non-nominal, or by reworking things so that a tuple is a nominal type with a 
> single variadic generic parameter.
> 
> Slava
> 
>> On Nov 20, 2017, at 9:06 PM, Tony Allevato via swift-evolution 
>> > wrote:
>> 
>> This is something I've wanted to look at for a while. A few weeks ago I 
>> pushed out https://github.com/apple/swift/pull/12598 
>>  to extend the existing synthesis 
>> to handle structs/enums when a field/payload has a tuple of things that are 
>> Equatable/Hashable, and in that PR it was (rightly) observed, as Chris just 
>> did, that making tuples conform to protocols would be a more general 
>> solution that solves the same problem you want to solve here.
>> 
>> I'd love to dig into this more, but last time I experimented with it I got 
>> stuck on places where the protocol conformance machinery expects 
>> NominalTypeDecls, and I wasn't sure where the right place to hoist that 
>> logic up to was (since tuples don't have a corresponding Decl from what I 
>> can tell). Any pointers?
>> 
>> On Mon, Nov 20, 2017 at 5:51 PM Chris Lattner via swift-evolution 
>> > wrote:
>> On Nov 20, 2017, at 5:48 PM, Kelvin Ma > > wrote:
>>> the end goal here is to use tuples as a compatible currency type, to that 
>>> end it makes sense for these three protocols to be handled as “compiler 
>>> magic” and to disallow users from manually defining tuple conformances 
>>> themselves. i’m not a fan of compiler magic, but Equatable, Hashable, and 
>>> Comparable are special because they’re the basis for a lot of standard 
>>> library functionality so i think the benefits of making this a special 
>>> supported case outweigh the additional language opacity.
>> 
>> I understand your goal, but that compiler magic can’t exist until there is 
>> something to hook it into.  Tuples can’t conform to protocols right now, so 
>> there is nothing that can be synthesized.
>> 
>> -Chris
>> 
>> 
>>> 
>>> On Mon, Nov 20, 2017 at 8:42 PM, Chris Lattner >> > wrote:
>>> 
 On Nov 20, 2017, at 5:39 PM, Kelvin Ma via swift-evolution 
 > wrote:
 
 when SE-185 
 
  went through swift evolution, it was agreed that the next logical step 
  is 
 synthesizing these conformances for tuple types, though it was left out of 
 the original proposal to avoid mission creep. I think now is the time to 
 start thinking about this. i’m also tacking on Comparable to the other two 
 protocols because there is precedent in the language from SE-15 
 
  that tuple comparison is something that makes sense to write.
 
 EHC conformance is even more important for tuples than it is for structs 
 because tuples effectively have no workaround whereas in structs, you 
 could just manually implement the conformance. 
>>> 
>>> In my opinion, you’re approaching this from the wrong direction.  The 
>>> fundamental problem here is that tuples can’t conform to a protocol.  If 
>>> they could, synthesizing these conformances would be straight-forward.
>>> 
>>> If you’re interested in pushing this forward, the discussion is “how do 
>>> non-nominal types like tuples and functions conform to 

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Slava Pestov via swift-evolution]

Ignoring synthesized conformances for a second, think about how you would 
manually implement a conformance of a tuple type to a protocol. You would need 
some way to statically “iterate” over all the component types of the tuple — in 
fact this is the same as having variadic generics.

If we had variadic generics, we could implement tuples conforming to protocols, 
either by refactoring the compiler to allow conforming types to be non-nominal, 
or by reworking things so that a tuple is a nominal type with a single variadic 
generic parameter.

Slava

> On Nov 20, 2017, at 9:06 PM, Tony Allevato via swift-evolution 
>  wrote:
> 
> This is something I've wanted to look at for a while. A few weeks ago I 
> pushed out https://github.com/apple/swift/pull/12598 
>  to extend the existing synthesis 
> to handle structs/enums when a field/payload has a tuple of things that are 
> Equatable/Hashable, and in that PR it was (rightly) observed, as Chris just 
> did, that making tuples conform to protocols would be a more general solution 
> that solves the same problem you want to solve here.
> 
> I'd love to dig into this more, but last time I experimented with it I got 
> stuck on places where the protocol conformance machinery expects 
> NominalTypeDecls, and I wasn't sure where the right place to hoist that logic 
> up to was (since tuples don't have a corresponding Decl from what I can 
> tell). Any pointers?
> 
> On Mon, Nov 20, 2017 at 5:51 PM Chris Lattner via swift-evolution 
> > wrote:
> On Nov 20, 2017, at 5:48 PM, Kelvin Ma  > wrote:
>> the end goal here is to use tuples as a compatible currency type, to that 
>> end it makes sense for these three protocols to be handled as “compiler 
>> magic” and to disallow users from manually defining tuple conformances 
>> themselves. i’m not a fan of compiler magic, but Equatable, Hashable, and 
>> Comparable are special because they’re the basis for a lot of standard 
>> library functionality so i think the benefits of making this a special 
>> supported case outweigh the additional language opacity.
> 
> I understand your goal, but that compiler magic can’t exist until there is 
> something to hook it into.  Tuples can’t conform to protocols right now, so 
> there is nothing that can be synthesized.
> 
> -Chris
> 
> 
>> 
>> On Mon, Nov 20, 2017 at 8:42 PM, Chris Lattner > > wrote:
>> 
>>> On Nov 20, 2017, at 5:39 PM, Kelvin Ma via swift-evolution 
>>> > wrote:
>>> 
>>> when SE-185 
>>> 
>>>  went through swift evolution, it was agreed that the next logical step 
>>>  is 
>>> synthesizing these conformances for tuple types, though it was left out of 
>>> the original proposal to avoid mission creep. I think now is the time to 
>>> start thinking about this. i’m also tacking on Comparable to the other two 
>>> protocols because there is precedent in the language from SE-15 
>>> 
>>>  that tuple comparison is something that makes sense to write.
>>> 
>>> EHC conformance is even more important for tuples than it is for structs 
>>> because tuples effectively have no workaround whereas in structs, you could 
>>> just manually implement the conformance. 
>> 
>> In my opinion, you’re approaching this from the wrong direction.  The 
>> fundamental problem here is that tuples can’t conform to a protocol.  If 
>> they could, synthesizing these conformances would be straight-forward.
>> 
>> If you’re interested in pushing this forward, the discussion is “how do 
>> non-nominal types like tuples and functions conform to protocols”?
>> 
>> -Chris
>> 
>> 
>> 
>> 
>> 
> ___
> 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] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Tony Allevato via swift-evolution]

This is something I've wanted to look at for a while. A few weeks ago I
pushed out https://github.com/apple/swift/pull/12598 to extend the existing
synthesis to handle structs/enums when a field/payload has a tuple of
things that are Equatable/Hashable, and in that PR it was (rightly)
observed, as Chris just did, that making tuples conform to protocols would
be a more general solution that solves the same problem you want to solve
here.

I'd love to dig into this more, but last time I experimented with it I got
stuck on places where the protocol conformance machinery expects
NominalTypeDecls, and I wasn't sure where the right place to hoist that
logic up to was (since tuples don't have a corresponding Decl from what I
can tell). Any pointers?

On Mon, Nov 20, 2017 at 5:51 PM Chris Lattner via swift-evolution <
swift-evolution@swift.org> wrote:

> On Nov 20, 2017, at 5:48 PM, Kelvin Ma  wrote:
>
> the end goal here is to use tuples as a compatible currency type, to that
> end it makes sense for these three protocols to be handled as “compiler
> magic” and to disallow users from manually defining tuple conformances
> themselves. i’m not a fan of compiler magic, but Equatable, Hashable, and
> Comparable are special because they’re the basis for a lot of standard
> library functionality so i think the benefits of making this a special
> supported case outweigh the additional language opacity.
>
>
> I understand your goal, but that compiler magic can’t exist until there is
> something to hook it into.  Tuples can’t conform to protocols right now, so
> there is nothing that can be synthesized.
>
> -Chris
>
>
>
> On Mon, Nov 20, 2017 at 8:42 PM, Chris Lattner 
> wrote:
>
>>
>> On Nov 20, 2017, at 5:39 PM, Kelvin Ma via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> when SE-185
>> 
>> went through swift evolution, it was agreed that the next logical step
>> 
>> is synthesizing these conformances for tuple types, though it was left out
>> of the original proposal to avoid mission creep. I think now is the time to
>> start thinking about this. i’m also tacking on Comparable to the other
>> two protocols because there is precedent in the language from SE-15
>> 
>> that tuple comparison is something that makes sense to write.
>>
>> EHC conformance is even more important for tuples than it is for structs
>> because tuples effectively have no workaround whereas in structs, you could
>> just manually implement the conformance.
>>
>>
>> In my opinion, you’re approaching this from the wrong direction.  The
>> fundamental problem here is that tuples can’t conform to a protocol.  If
>> they could, synthesizing these conformances would be straight-forward.
>>
>> If you’re interested in pushing this forward, the discussion is “how do
>> non-nominal types like tuples and functions conform to protocols”?
>>
>> -Chris
>>
>>
>>
>>
>>
> ___
> 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] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Xiaodi Wu via swift-evolution]

Agree: I think it’s painfully obvious that we want tuples to conform to
Equatable under the appropriate circumstances. Whether this is magic or not
is not strictly settled (though I agree with Kelvin that magic is sensible
here), but right now the issue is that tuples can’t conform to protocols at
all and they very much need to be able to—but how?

On Mon, Nov 20, 2017 at 20:51 Chris Lattner via swift-evolution <
swift-evolution@swift.org> wrote:

> On Nov 20, 2017, at 5:48 PM, Kelvin Ma  wrote:
>
> the end goal here is to use tuples as a compatible currency type, to that
> end it makes sense for these three protocols to be handled as “compiler
> magic” and to disallow users from manually defining tuple conformances
> themselves. i’m not a fan of compiler magic, but Equatable, Hashable, and
> Comparable are special because they’re the basis for a lot of standard
> library functionality so i think the benefits of making this a special
> supported case outweigh the additional language opacity.
>
>
> I understand your goal, but that compiler magic can’t exist until there is
> something to hook it into.  Tuples can’t conform to protocols right now, so
> there is nothing that can be synthesized.
>
> -Chris
>
>
>
> On Mon, Nov 20, 2017 at 8:42 PM, Chris Lattner 
> wrote:
>
>>
>> On Nov 20, 2017, at 5:39 PM, Kelvin Ma via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> when SE-185
>> 
>> went through swift evolution, it was agreed that the next logical step
>> 
>> is synthesizing these conformances for tuple types, though it was left out
>> of the original proposal to avoid mission creep. I think now is the time to
>> start thinking about this. i’m also tacking on Comparable to the other
>> two protocols because there is precedent in the language from SE-15
>> 
>> that tuple comparison is something that makes sense to write.
>>
>> EHC conformance is even more important for tuples than it is for structs
>> because tuples effectively have no workaround whereas in structs, you could
>> just manually implement the conformance.
>>
>>
>> In my opinion, you’re approaching this from the wrong direction.  The
>> fundamental problem here is that tuples can’t conform to a protocol.  If
>> they could, synthesizing these conformances would be straight-forward.
>>
>> If you’re interested in pushing this forward, the discussion is “how do
>> non-nominal types like tuples and functions conform to protocols”?
>>
>> -Chris
>>
>>
>>
>>
>>
> ___
> 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] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Chris Lattner via swift-evolution]

On Nov 20, 2017, at 5:48 PM, Kelvin Ma  wrote:
> the end goal here is to use tuples as a compatible currency type, to that end 
> it makes sense for these three protocols to be handled as “compiler magic” 
> and to disallow users from manually defining tuple conformances themselves. 
> i’m not a fan of compiler magic, but Equatable, Hashable, and Comparable are 
> special because they’re the basis for a lot of standard library functionality 
> so i think the benefits of making this a special supported case outweigh the 
> additional language opacity.

I understand your goal, but that compiler magic can’t exist until there is 
something to hook it into.  Tuples can’t conform to protocols right now, so 
there is nothing that can be synthesized.

-Chris


> 
> On Mon, Nov 20, 2017 at 8:42 PM, Chris Lattner  > wrote:
> 
>> On Nov 20, 2017, at 5:39 PM, Kelvin Ma via swift-evolution 
>> > wrote:
>> 
>> when SE-185 
>> 
>>  went through swift evolution, it was agreed that the next logical step 
>>  is 
>> synthesizing these conformances for tuple types, though it was left out of 
>> the original proposal to avoid mission creep. I think now is the time to 
>> start thinking about this. i’m also tacking on Comparable to the other two 
>> protocols because there is precedent in the language from SE-15 
>> 
>>  that tuple comparison is something that makes sense to write.
>> 
>> EHC conformance is even more important for tuples than it is for structs 
>> because tuples effectively have no workaround whereas in structs, you could 
>> just manually implement the conformance. 
> 
> In my opinion, you’re approaching this from the wrong direction.  The 
> fundamental problem here is that tuples can’t conform to a protocol.  If they 
> could, synthesizing these conformances would be straight-forward.
> 
> If you’re interested in pushing this forward, the discussion is “how do 
> non-nominal types like tuples and functions conform to protocols”?
> 
> -Chris
> 
> 
> 
> 
> 

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

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Kelvin Ma via swift-evolution]

the end goal here is to use tuples as a compatible currency type, to that
end it makes sense for these three protocols to be handled as “compiler
magic” and to disallow users from manually defining tuple conformances
themselves. i’m not a fan of compiler magic, but Equatable, Hashable, and
Comparable are special because they’re the basis for a lot of standard
library functionality so i think the benefits of making this a special
supported case outweigh the additional language opacity.

On Mon, Nov 20, 2017 at 8:42 PM, Chris Lattner  wrote:

>
> On Nov 20, 2017, at 5:39 PM, Kelvin Ma via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> when SE-185
> 
> went through swift evolution, it was agreed that the next logical step
>  is
> synthesizing these conformances for tuple types, though it was left out of
> the original proposal to avoid mission creep. I think now is the time to
> start thinking about this. i’m also tacking on Comparable to the other
> two protocols because there is precedent in the language from SE-15
> 
> that tuple comparison is something that makes sense to write.
>
> EHC conformance is even more important for tuples than it is for structs
> because tuples effectively have no workaround whereas in structs, you could
> just manually implement the conformance.
>
>
> In my opinion, you’re approaching this from the wrong direction.  The
> fundamental problem here is that tuples can’t conform to a protocol.  If
> they could, synthesizing these conformances would be straight-forward.
>
> If you’re interested in pushing this forward, the discussion is “how do
> non-nominal types like tuples and functions conform to protocols”?
>
> -Chris
>
>
>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Chris Lattner via swift-evolution]

> On Nov 20, 2017, at 5:39 PM, Kelvin Ma via swift-evolution 
>  wrote:
> 
> when SE-185 
> 
>  went through swift evolution, it was agreed that the next logical step 
>  is 
> synthesizing these conformances for tuple types, though it was left out of 
> the original proposal to avoid mission creep. I think now is the time to 
> start thinking about this. i’m also tacking on Comparable to the other two 
> protocols because there is precedent in the language from SE-15 
> 
>  that tuple comparison is something that makes sense to write.
> 
> EHC conformance is even more important for tuples than it is for structs 
> because tuples effectively have no workaround whereas in structs, you could 
> just manually implement the conformance. 

In my opinion, you’re approaching this from the wrong direction.  The 
fundamental problem here is that tuples can’t conform to a protocol.  If they 
could, synthesizing these conformances would be straight-forward.

If you’re interested in pushing this forward, the discussion is “how do 
non-nominal types like tuples and functions conform to protocols”?

-Chris




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