[swift-evolution] SE-0066 Reaction

Mishal Awadah a.mamish at gmail.com
Wed Apr 27 11:48:00 CDT 2016

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 <cacoyi at gmail.com> 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 <
> swift-evolution at swift.org> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160427/81793a21/attachment.html>

More information about the swift-evolution mailing list