Hi, Please find my comment in body:
BR, Radek Smogura > On 27 Dec 2015, at 22:08, Taras Zakharko <[email protected]> wrote: > > >> On 27 Dec 2015, at 21:55, Mosab Elagha <[email protected] >> <mailto:[email protected]>> 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 <[email protected] >> <mailto:[email protected]>> wrote: >> Hi, >> >> That’s a great idea! >> >> Kind regards, >> Radek >> >> > On 27 Dec 2015, at 21:10, Taras Zakharko via swift-evolution >> > <[email protected] <mailto:[email protected]>> 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 >> > [email protected] <mailto:[email protected]> >> > https://lists.swift.org/mailman/listinfo/swift-evolution >> > <https://lists.swift.org/mailman/listinfo/swift-evolution> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
