Sorry, this was meant to be in response to: https://github.com/apple/swift-evolution/blob/master/proposals/0110-distingish-single-tuple-arg.md
From James F > On 2 Jul 2016, at 04:02, James Froggatt <[email protected]> wrote: > > I've made a separate topic discussing the possible consequences of this > change, but I don't think the implications are really worth it. Parameter > lists and tuples are fundamentally similar, and that's why we're getting all > of these confusing edge cases. > > Ultimately, this come down to two problems: > > • Casting between functions of different labels is confusing. We've discussed > removing argument labels from function types for this reason. However, tuples > have this exact same problem. We should solve this generally, for tuples and > functions. A solution applicable to one is applicable to the other. If tuples > were only in the languages because they were meant to model a function's > arguments, I believe they still do in Swift 2. > > Perhaps a tuple's argument labels should be in the name of it's containing > variable, like we plan for function types? > > • Parameter lists have distinct annotations, which are unsuitable for full > exposure to the type system. However, I think this can be resolved through > something similar to the @noescape annotation, but for tuples, to restrict > them to ‘pure, nonescaping’ functional contexts (IE direct application to a > function). > > For example: > > apply<A, B>(in: @params A, function: A -> B) -> B { > return function(in) > } > > //since we know the tuple cannot escape, > //only be passed to more functions with the exact parameter list represented > by A, > //we can safely use it with parameter decorations in a strictly functional > context: > > apply(in: (&mutable, other), function: aFunction) > > //or more practically: > > (&mutable, other) => aFunction > > Any return value is naturally escaping, meaning a returned tuple cannot have > modifiers such as @noescape and inout, since it can't provide that guarantee. > I think this addresses the problem much more directly. > > There are inherently parallels between parameter lists and tuples, and that's > why functional programming languages rely on them. Swift actually has quite a > limited number of parameter list modifiers, so I think it's worth exploring > alternatives to fit these into the existing, much more generalised system, > before removing the parallel between parameter lists and tuples in favour of > something already known to be less flexible. > > My review is inline. > >> On 30 Jun 2016, at 19:26, Chris Lattner <[email protected]> wrote: >> >> Hello Swift community, >> >> The review of "SE-0111: Remove type system significance of function argument >> labels" begins now and runs through July 4. The proposal is available here: >> >> >> https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md >> >> Reviews are an important part of the Swift evolution process. All reviews >> should be sent to the swift-evolution mailing list at >> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> or, if you would like to keep your feedback private, directly to the review >> manager. >> >> What goes into a review? >> >> The goal of the review process is to improve the proposal under review >> through constructive criticism and contribute to the direction of Swift. >> When writing your review, here are some questions you might want to answer >> in your review: >> >> * What is your evaluation of the proposal? > > Strongly against, for the reasons described. > >> * Is the problem being addressed significant enough to warrant a change to >> Swift? > > Yes, but we should explore the alternatives. > >> * Does this proposal fit well with the feel and direction of Swift? > > Absolutely not, we will lose fundamental to Swift something by making this > change. We've already seen it by ‘removing’ tuple splat, and finding it to be > only surface-level. This is something already deeply ingrained in the type > system, and which provides a good deal of flexibility to functional code. The > addition of Never in favour of @noreturn shows how powerful the type system > can be, and I don't think we should walk this path half-heartedly. > >> * If you have used other languages or libraries with a similar feature, >> how do you feel that this proposal compares to those? > > I got started programming back in Objective-C, but most of my programming > experience is with Swift. In the various other (admittedly older) imperative > languages I've tried, I have been disappointed by the inflexibility of things > such as: > > • Lack of tuple support, for straightforward return of >1 value where a > formal type is overkill. > • Lack of explicit optionals, or tacked-on optional support which interacts > poorly with generics and existing libraries. > • Lack of equal support for value-types, to varying degrees. > • Generics aren't actually generic, often requiring overloads for > value-types, due to their ‘defaulting’ behaviour. > > The one thing these all have in common is the type system. There seems to be > real progress to be made by generalizing the type system as Swift has, so far. > > Swift's functional generics system is incredible, largely thanks to the > modelling of parameter lists as a type, namely tuples. While this model has > fallen behind language advances, I think it can and should be brought up to > speed. > >> * How much effort did you put into your review? A glance, a quick reading, >> or an in-depth study? >> > > A lot of thought, while working with Swift and other languages. > > Thanks for reading. > >> More information about the Swift evolution process is available at >> >> https://github.com/apple/swift-evolution/blob/master/process.md >> >> Thank you, >> >> -Chris Lattner >> Review Manager >> >> >> _______________________________________________ >> swift-evolution-announce mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution-announce
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
