> On Nov 10, 2017, at 5:44 PM, Chris Lattner <[email protected]> wrote: > >> On Nov 10, 2017, at 11:42 AM, Joe Groff via swift-evolution >> <[email protected]> wrote: >>>> >>>> On Nov 10, 2017, at 10:57 AM, Alejandro Martinez via swift-evolution >>>> <[email protected]> wrote: >>>> >>>> This seems a really interesting solution Chris. >>>> Similar to what Joe mentions I think this would also be appreciated by >>>> the community to make even nicer DSLs in Swift, which may or may not >>>> be a good side effect of the proposal. >>>> Also, I'm just wondering, how much complication adds this to the >>>> compiler itself that would have to be maintained in the future? >>> >>> This is a very localized and simple change to the compiler. Assuming the >>> pitch process goes well, I will provide an implementation. >> >> I don't think it's that localized. It's going to make call resolution >> massively more complicated. Through great pain and community anguish, we >> pushed ourselves to a model where argument labels are parts of the >> declaration name, not part of the call argument, and this would throw us >> straight back into the kinds of complications of dealing with overloaded >> name- and type-dependent behavior we're trying to get away from in the >> language. > > I’m pretty sure it doesn’t, but good news: since Swift requires an > implementation before the proposal can be officially reviewed, you will be > able to look at the actual patch to make this decision.
And the goal of the pitch phase is to hopefully save you the tears of trying to implement something if it's a bad idea. >> Swift is a dynamic language too, and tuples have enough metadata in them >> that you could get almost everything you want with an infix operator. > > This is really gross. The goal here is to make Python feel natural. If you > oppose this proposal then we’ll have to find some other way to provide an > elegant experience: >> x∫(0, "foo", bar: "bas”) > > This is not going to be acceptable to users. Is it? My choice of operator character is silly, but it's the same amount of syntactic overhead as an optional chain/force call. It's a fair sight better than x.call(args: ..., keywordArgs: ...), I hope you'd agree, and is something that works without any language change. You mentioned variadics as being inadequate for your purposes as a considered alternative, but a variadics model that wasn't based on type erasure to arrays and kept runtime type information about the argument tuple that was passed in, along with better reflection APIs for accessing that type info, might lead to something you can use by incrementally improving the expressivity of existing language features instead of adding new ones. -Joe _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
