I initially had similar concerns to Mishal, but I worked my way through it and found I was wrong.
In current Swift you can have a function: A -> B -> C Adding brackets for clarity, that is equivalent to this (current Swift): A -> (B -> C) After this proposal this will become: (A) -> ((B) -> C) Which can also be expressed (with proposal): (A) -> (B) -> C I don't think this is making it harder to do what you want. I think that's what Chris meant. Please correct me if I'm wrong Chris :) By my interpretation it is just removing the syntactic ambiguity between: * a single argument that is a tuple of type: (A, B, C) * multiple arguments: A, B, C This is a small change with a big win. On Wednesday, 27 April 2016, Ryan Lovelett via swift-evolution < [email protected]> wrote: > SE-0066 is a very narrow proposal - it only affects syntax, not > semantics. The type system semantics that you seem interested in are > unlikely to happen regardless of the syntax changes SE-0066 imply, and > SE-0066 doesn’t have anything to do with that. > > > It is most disappointing to read these sorts of statements. > > One of the things that I have noticed over the last year or so of working > with Swift is a trend in the community of libriaries being written for > Swift towards some of these "system semantics" (i.e., functional paradigms) > like applicatives and such. > > Granted I may have a selection bias towards these sorts of libraries. That > is, I tried one library that did some of this stuff so then I tried more. > Eventually stumbling into an enclave of functional practioners of Swift. > I'm willing to admit that I have not conducted a scientific survey. > > But from my vantage we have a minority of Swift users participating in > these evolution discussions. Albeit, judging from the e-mail volume, an > extremely _vocal_ minority. I worry that these things become an echo > chamber and those not involved will look at some of the "writing on the > wall" and think differently about Swift going forward. Indeed for those > people they may look at Swift 3 and say "I did not leave Swift; Swift left > me." > > What is more is that those not participating in these discussions now may > leave them with no recourse to be heard. Because apparently Swift 3 is a > do-or-die release (or as the author of this evolution put it: "It is now or > never."). I wonder what portion of Swift developers, the ones who want to > see Swift be their go-to language for the forseable future, understand the > implications or justifications for a Swift 3 release. > > All that having been said, I get it, decisions are made by those who show > up. Roger that. I also understand and agree with the desire to make Swift > its own language. To show restraint at the urge to turn the language into a > hodge podge of the "greatest hits" of language paradigms. I sincerely > appreciate the difficulty of the task for the Swift core team. > > I realized at the end that I do not really have a point. Apparently I'm > feeling philosphical this Wednesday morning. >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
