> What I’m trying to say is that there are a lot of reasons that the Swift > type system works the way it does (e.g. inout has very specific behavior that > doesn’t work when partially applied, we have specific promotion rules that > apply only in argument lists etc). These reasons and features are certainly > debatable, but have nothing to do with SE-0066, therefore they seem out of > scope for a discussion of SE-0066 to go into.
I agree, but although the model of small changes with immediate benefit has advantages, I think "the big picture" is to important to be ignored. I don't think this is the case, but those of us whose only source of information is this list have a viewpoint that is narrow compared to a member of the core team (that's just natural — publishing every conversation isn't practical). Coming back to the topic, there must have been a reason to start with a model where all functions take a single parameter (which might be a tuple), and there must be a good reason to dissociate from that principle. I think actually knowing those motivations would be beneficial for the evolution process: Although it's discouraged to discuss proposals with ground shaking consequences here on the list, sharing more of the long-term vision for Swift could help focusing on topics that fit into that vision. (of course, I might just be missing an important post here or in the Swift blog, so please be patient with me if this is the case) Best regards, Tino _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
