I think the Core Team initially (pre-Swift 1) wanted to make tuples and arguments isomorphic. But that model has many downsides which forced us to backtrack from that model:
• Modifiers on arguments (like inout) would force us to introduce them as part of the type-system on tuples, which makes for a messy model, • Tuple structuring and de-structuring greatly complicates the work of the type-checker. The decision was made early in the Swift-evolution timeframe to strip what was left of the old model. It's much too late to backtrack now. Even if one wanted to, you'd have to address the original concerns that drove us to the current model. David. > On 24 Jun 2017, at 21:12, Djura Retired Hunter via swift-evolution > <swift-evolution@swift.org> wrote: > >>>> >>>> >>>>> On Jun 23, 2017, at 7:46 AM, Elviro Rocca via swift-evolution >>>>> <swift-evolution@swift.org> wrote: >>>>> >>>>> It's probably late to just casually add a couple of cents to a discussion >>>>> that has been going for so long, but it seems to me that from a user >>>>> standpoint, that uses types to structure their programs and define logic >>>>> and relationships, isomorphic types should be considered the same by the >>>>> compiler. The added burden of distinguishing between, to say, a function >>>>> that takes 2 arguments and one that takes a single tuple of two arguments >>>>> doesn't seem useful at all, at least from the standpoint of the types >>>>> involves. All the rest, like named parameters or tuple labels, are just >>>>> really about style and convenience, but isomorphic types, while not >>>>> strictly equal (the very concept of "equal" is in fact a huge deal in >>>>> abstract mathematics) are for all means "equivalent" for the >>>>> world-modeler. >>>> >>>> Doesn’t seem useful?… >>>> >>>> let myFunc: (MyTypeAlias) -> Int = /* … */ >>>> >>>> Does the function pointer have a single parameter? Or does it trigger >>>> Super-Secret Tuple-Destructing mode and actually indicate two parameters? >>>> My secret unknown single type should always be a single type, no matter >>>> what kind of type it is. >> >> (A, B, C) ((A, B), C) (A, (B, C)) >> >> You’re saying partitions aren’t important. I’m saying that they are. Even >> though the second two tuples above are implemented like the first, I >> wouldn’t want them to be indistinguishable from an user’s standpoint. I >> wouldn’t want my two-argument functions magically become a three-argument >> one due to implementation details. > > Why are partitions, just partitions, of tuples important? And why should > anybody even consider writing a function that takes a tuple as "single > argument" instead of just taking two arguments? > > The difference between the following two functions is completely meaningless > from a user standpoint: > > func x<A,B> (tuple: (first: A, second: B)) > func y<A,B> (first: A, second: B) > >> >> My previous example will stay an one-argument function for any non-tuple >> type behind the alias. But if it’s a tuple type, my assumption breaks >> because your rules would ban tuples from being first-class types. >> > > > What? Why my rules say that tuples are not first class types? I'm just saying > that equivalent tuples should be allowed as arguments for functions that take > equivalent tuples as arguments. > > You examples shows a function that takes a "MyTypeAlias" as input: > > - if MyTypeAlias is an alias for, say, a "Person", that function can be > called with an instance of "Person" > - if MyTypeAlias is an alias for (Int,Int), that function can be called with > a couple of Int > > What's the matter? > > > Elviro > > _______________________________________________ > 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
