The most common use-case for this is with Cocoa classes, which are not set up for fluent implementation. A preliminary proposal (which I am not updating since the matter was referred to the bug report system) is here: https://gist.github.com/erica/6794d48d917e2084d6ed Hopefully it explains the reason this would add to the Apple development ecosystem. The bug report is here: https://bugs.swift.org/browse/SR-160
-- E > On Dec 27, 2015, at 6:24 PM, Howard Lovatt <howard.lov...@gmail.com> wrote: > > -1 doesn't seem worth adding it is not a lot of trouble to type `obj.` at the > start of every line. Also if an API is intended to be used like that its > methods would return `self` and it would be used in a FLUENT style. > > Sent from my iPad > > On 28 Dec 2015, at 9:00 AM, Erica Sadun via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > >> I believe this has popped up on-list a few times. Search for method cascades: >> >> cascading site:https://lists.swift.org/pipermail/swift-evolution/ >> <http://lists.swift.org/pipermail/swift-evolution/> >> >> https://www.google.com/?gws_rd=ssl#q=cascading+site:https:%2F%2Flists.swift.org%2Fpipermail%2Fswift-evolution%2F >> >> <https://www.google.com/?gws_rd=ssl#q=cascading+site:https:%2F%2Flists.swift.org%2Fpipermail%2Fswift-evolution%2F> >> >> Other search terms include dart, initializers, ".." (although that may be >> hard to look for) >> >> -- E >> >> >>> On Dec 27, 2015, at 2:34 PM, Radosław Smogura via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>> >>> Hi, >>> >>> Please find my comment in body: >>> >>> BR, >>> Radek Smogura >>>> On 27 Dec 2015, at 22:08, Taras Zakharko <taras.zakha...@uzh.ch >>>> <mailto:taras.zakha...@uzh.ch>> wrote: >>>> >>>> >>>>> On 27 Dec 2015, at 21:55, Mosab Elagha <mosabela...@gmail.com >>>>> <mailto:mosabela...@gmail.com>> wrote: >>>>> >>>>> Agreed, this seems like a great idea. Looks like it would also allow for >>>>> a lot of customization - for example out of one "template" object. >>>>> >>>>> Would the object have to already be initialized or could you initialize >>>>> it from this? IMO it would have to already be initialized or else it >>>>> might lead to confusion. >>>> >>>> The object could be any kind of valid Swift entity that has members (where >>>> you would usually use . to access them): object instance, type, struct >>>> etc. I can also imagine combining it with assignment, e.g. instead of >>>> >>>> let obj = MyClass() >>>> do with obj { >>>> prop1 = v1 >>>> setup2() >>>> } >>>> >>>> a combined assignment form such as >>>> >>>> do with let obj = MyClass() { >>>> prop1 = v1 >>>> setup2() >>>> } >>> I think in this case it’s important to define scope of obj - it should be >>> only “do with”, not the the outer one? >>> >>>> But this clashes with optional binding, so it might be not a good idea. >>>> >>>>> Also, would this be limited to instance methods? >>>> >>>> Anything you can access with the dot notation. >>>> >>>>> >>>>> -Mosab Elagha >>>>> >>>>> On Sun, Dec 27, 2015 at 3:13 PM, Radosław Smogura >>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>>>> Hi, >>>>> >>>>> That’s a great idea! >>>>> >>>>> Kind regards, >>>>> Radek >>>>> >>>>> > On 27 Dec 2015, at 21:10, Taras Zakharko via swift-evolution >>>>> > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>>>> > >>>>> > Quite often, one needs to perform a number of operations on a single >>>>> > object (e.g. call up a bunch of configuration or action methods). This >>>>> > proposal is to extend the ‘do' statement with an explicit lexical >>>>> > scope feature. For instance, this piece of code >>>>> > >>>>> > object.do_something() >>>>> > object.do_somethind_else() >>>>> > object.prop1 = value >>>>> > >>>>> > becomes >>>>> > >>>>> > do with object // or with object do >>>>> > { >>>>> > do_something() >>>>> > do_somethind_else() >>>>> > prop1 = value >>>>> > } >>>>> > >>>>> > Essentially, this construct would introduce a level of lexical scope — >>>>> > explicitly controlled by the programmer, in addition to the implicit >>>>> > scope dictated by statement blocks, closures and self. >>>>> > >>>>> > The advantage of this construct is that it allows one to remove >>>>> > boilerplate code for initialisation/configuration as well as adds clear >>>>> > logical separation to the code. Disadvantage is potential shadowing of >>>>> > identifiers in the scope, but this should to be a big issue because the >>>>> > syntax is explicit rather then implicit, meaning that its the >>>>> > programmers job to make sure that no shadowing occurs (btw, compiler >>>>> > could warn about shadowing). The additions to the language syntax is >>>>> > minimal and the implementation should be straightforward (its >>>>> > essentially the same logic as for self). >>>>> > >>>>> > Note that this proposal is close to the discussion about popular the >>>>> > implicit self on this mailing list. A body of any method could be >>>>> > understood as wrapped into an implicit >>>>> > >>>>> > do with self {} >>>>> > >>>>> > Finally, this construct exists in a very similar form in Pascal (no >>>>> > idea if Wirth was inspired by some other feature or not here) and is >>>>> > also present in a bunch of languages that have dynamic scope. >>>>> > Personally, I use it all the time in R and I am loving it. >>>>> > >>>>> > If the community thinks this could be a nice addition to the language, >>>>> > I am ready to draft a proposal. Also, apologies if this has been >>>>> > suggested before — it is impossible to keep up with this list. >>>>> > >>>>> > Best, >>>>> > >>>>> > Taras >>>>> > _______________________________________________ >>>>> > swift-evolution mailing list >>>>> > swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>>> > https://lists.swift.org/mailman/listinfo/swift-evolution >>>>> > <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>>> >>>>> _______________________________________________ >>>>> swift-evolution mailing list >>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>>> >>>> >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
