[swift-evolution] Method cascading (was Re: Request for Discussion: Setup closures)

[Kenny Leung]

I’m not proposing “.{}”, but object.{}, analogous to object.property or object.method(). I don’t think this would be ambiguous.

-Kenny


> On Dec 14, 2015, at 2:49 PM, Erica Sadun via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Joe Groff pointed out that a leading . was syntactically ambiguous. From 7 December 2015:
> 
>> Note that using leading '.' is syntactically ambiguous. The above already parses as `.thing = 42.otherThing("meaning of life")` (or would, if we didn't already ban statements from starting with '.' for exactly this reason).
>> 
>> -Joe
> 
> -- E
> 
> 
>> On Dec 14, 2015, at 2:02 AM, Jacob Bandes-Storch via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> Would .{} be a special syntax in the grammar, or an instance of a custom operator taking advantage of some more generic self-rebinding? Would you be able to write a custom function taking such a block and applying it later (à la instance_eval <http://ruby-doc.org/core-2.2.0/BasicObject.html#method-i-instance_eval>)?
>> 
>> Jacob
>> 
>> On Mon, Dec 14, 2015 at 12:03 AM, Pierre Monod-Broca via swift-evolution <swift-evolution at swift.org> wrote:
>> +1, the .{} syntax is nice
>> 
>> Pierre
>> 
>> > Le 11 déc. 2015 à 18:05, Kenny Leung via swift-evolution <swift-evolution at swift.org> a écrit :
>> >
>> > I’m all for this, but couldn’t it be done without the “with”? It doesn’t seem to make the code read any easier.
>> >
>> > This
>> >
>> >    myObject {
>> >        this = that
>> >        here = there
>> >    }
>> >
>> > could unambiguously indicate that you want method cascading.
>> >
>> > Or even
>> >
>> >    myObject.{
>> >        this = that
>> >        here = there
>> >    }
>> >
>> > which has a relationship to the current method invocation syntax.
>> >
>> > -Kenny
>> >
>> >
>> >> On Dec 9, 2015, at 9:47 AM, Erica Sadun via swift-evolution <swift-evolution at swift.org> wrote:
>> >>
>> >> Here you go:  https://bugs.swift.org/browse/SR-160
>> >>
>> >> Let me also point you to this:  https://gist.github.com/erica/6794d48d917e2084d6ed because
>> >>
>> >> * It is pretty
>> >> * I put a lot of effort into it, following the "social" request in the current process document, etc
>> >> * I want to publicly shower props on Sean Heber, who showed great patience, insight, and kindness helping out on this
>> >>
>> >> I'd appreciate any advice you could share on determining which tool to use when you have a Swift enhancement idea
>> >>
>> >> -- E
>> >>
>> >>
>> >>> On Dec 8, 2015, at 10:16 PM, Chris Lattner <clattner at apple.com> wrote:
>> >>>
>> >>>
>> >>>> On Dec 7, 2015, at 4:46 PM, Erica Sadun via swift-evolution <swift-evolution at swift.org> wrote:
>> >>>>
>> >>>> Noted. Since an updated proposal is all but ready, could we please have a Swift 4 proposal daycare folder to stick it in, so it doesn't get lost or forgotten?
>> >>>
>> >>> Personally, I’d rather use bugs.swift.org for feature requests like this.  It is lighter weight, allows commenting, etc.
>> >>>
>> >>> -Chris
>> >>>
>> >>
>> >>
>> >> _______________________________________________
>> >> swift-evolution mailing list
>> >> swift-evolution at swift.org
>> >> https://lists.swift.org/mailman/listinfo/swift-evolution
>> >
>> > _______________________________________________
>> > swift-evolution mailing list
>> > swift-evolution at swift.org
>> > https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>>  _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution