Ah, thank you for pointing this out! I think I would suggest a change or two to your proposal, but I need to flesh them out first. Is it possible to leave comments on the bug site? BTW, why was it delegated to the bug report system in the first place?
> On 28 Dec 2015, at 02:28, Erica Sadun via swift-evolution > <swift-evolution@swift.org> wrote: > > 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 > <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 > <https://bugs.swift.org/browse/SR-160> > > -- E > > >> On Dec 27, 2015, at 6:24 PM, Howard Lovatt <howard.lov...@gmail.com >> <mailto: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 <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
