Thanks for the feedback Chris! I am happy with this proposal given the discussion here.
- Mish On Wed, Apr 27, 2016 at 7:01 AM, Andrew Bennett <[email protected]> wrote: > 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
