Hi Elviro,
> On 23. Jun 2017, at 13:46, Elviro Rocca via swift-evolution
> <[email protected]> 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.
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
