[swift-evolution] Revisiting SE-0110

[Daniel Vollmer]

Hi Elviro,

> On 23. Jun 2017, at 13:46, Elviro Rocca via swift-evolution <swift-evolution at swift.org> wrote:

[snip]

> …by showing code that’s marginally different from each other, like one more nesting of parentheses, or one less label for a parameter. It seems to me that distinctions like these are just important at the compiler level, but not particularly useful from an usability standpoint.

It is your opinion that these distinctions are not “useful from a usability standpoint”. My opinion, for example, differs in that I think these distinctions in the structure of the types is very important, even if the types “information content” is the same. Structure also conveys information (and intent).

> The point is that, the following type couples are completely isomorphic to each other (meaning that they are, for all means, equivalent) and a smart type system could in theory consider them as the same thing:
> 
> (A) == ((A))
> (A) == (((A)))
> (A) == (A,())
> (A) == ((),A,())
> (A,B) == ((A,B))
> (A,B) == (((A,B)))
> (A,B) == (A,B,())
> (A,B) == ((),A,B,())
> (A,B) == ((),(A,B),())

To my mind, the examples should not compare equal (in fact, they shouldn’t even be comparable by default because for those distinct types involved that seems like a non-sensical question to me).

I might agree that a type system *could* consider these the same, but I don’t think it should. For example, in the context of generic programming, the structure of types (especially in degenerate cases such as e.g. empty tuples) should strictly match what is expected; calling a function that expects two tuples is not the same as calling that function with one tuple and so on. The same goes for nesting tuples.

That said, I do think there should be (better?) support for converting between representations, such as easily forming a tuple from a (variadic) argument list, and conversely splatting a tuple to arguments (not sure whether that’s the correct term—I’m talking about something like C++17’s std::apply).

> Again, I don't really expect these words to have any impact, considering the huge discussion that has been going, and I don't certainly intend to undermine any other contribution with my extremely generic statements. But I felt like writing this, and I did.

Same here. :)


Respectfully,
	Daniel.