Re: [swift-evolution] [Proposal] Lexical scope statement (with .. do)

[Taras Zakharko via swift-evolution]

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 
>  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 
>  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 > > 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 
>> > 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/ 
>>> 
>>> 
>>> 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 
 > wrote:
 
 Hi,
 
 Please find my comment in body:
 
 BR,
 Radek Smogura
> On 27 Dec 2015, at 22:08, Taras Zakharko  > wrote:
> 
> 
>> On 27 Dec 2015, at 21:55, Mosab Elagha > > 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 
>> > wrote:
>> Hi,
>> 
>> That’s a great idea!
>> 
>> Kind regards,
>> Radek
>> 
>> > On 27 Dec 2015, at 21:10, Taras Zakharko via swift-evolution 
>> > > 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 

Re: [swift-evolution] [Proposal] Lexical scope statement (with .. do)

[Tino Heth via swift-evolution]

> method cascades
I thought there was some sort of showstopper that ended further discussion for 
Swift 3 — but seems it wasn't the fault of the archive that I didn't find that 
reason ;-)

I'll use the opportunity to talk about my major motivation to want cascades in 
Swift:
Several years ago, I was quite bored by Objective-C and did an inquiry what 
other languages I might like.
I considered exotic choices like Vala (reference counted, compiled), but 
despite my dislike for garbage-collected systems, I also looked at the JVM.
At that time, my feeling was that many people were deeply impressed by some 
goodies Groovy had to offer, but didn't want to give up the benefits of type 
safety.
One of the major selling point for a nice contender called "Kotlin" has been 
"type safe, Groovy-style builders", and their use case might become very 
important for Swift as well.

I'll just show an example:
let page = HTML().{
  body.{
table.{
  tr.{
td.text("Cell content")
td.text("Another cell")
  }
}
div(color: .redColor()).text("Some text")
  }
}

// basic principle: directly start a method cascade on computed properties

This piece of code (I'm not using the proposed "with"-syntax but a light-weight 
alternative that I'd prefer) could generate a complete HTML-page, ready to be 
send to a browser — and the syntax is much easier than the generated markup 
itself!

With Swift on Linux, I'm quite sure generating HTML will become a very 
important task for the language.

Tino___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Lexical scope statement (with .. do)

[Taras Zakharko via swift-evolution]

> On 27 Dec 2015, at 21:55, Mosab Elagha  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()
}

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  > wrote:
> Hi,
> 
> That’s a great idea!
> 
> Kind regards,
> Radek
> 
> > On 27 Dec 2015, at 21:10, Taras Zakharko via swift-evolution 
> > > 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 
> > https://lists.swift.org/mailman/listinfo/swift-evolution 
> > 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Lexical scope statement (with .. do)

[Radosław Smogura via swift-evolution]

Hi,

That’s a great idea!

Kind regards,
Radek

> On 27 Dec 2015, at 21:10, Taras Zakharko via swift-evolution 
>  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
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Lexical scope statement (with .. do)

[Howard Lovatt via swift-evolution]

-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 
>  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/
> 
> 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 
>>  wrote:
>> 
>> Hi,
>> 
>> Please find my comment in body:
>> 
>> BR,
>> Radek Smogura
 On 27 Dec 2015, at 22:08, Taras Zakharko  wrote:
 
 
>>> 
 On 27 Dec 2015, at 21:55, Mosab Elagha  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 
>  wrote:
> Hi,
> 
> That’s a great idea!
> 
> Kind regards,
> Radek
> 
> > On 27 Dec 2015, at 21:10, Taras Zakharko via swift-evolution 
> >  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
> > 

Re: [swift-evolution] [Proposal] Lexical scope statement (with .. do)

[Erica Sadun via swift-evolution]

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  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 
> > 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/ 
>> 
>> 
>> 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 
>>> > wrote:
>>> 
>>> Hi,
>>> 
>>> Please find my comment in body:
>>> 
>>> BR,
>>> Radek Smogura
 On 27 Dec 2015, at 22:08, Taras Zakharko > wrote:
 
 
> On 27 Dec 2015, at 21:55, Mosab Elagha  > 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 
> > wrote:
> Hi,
> 
> That’s a great idea!
> 
> Kind regards,
> Radek
> 
> > On 27 Dec 2015, at 21:10, Taras Zakharko via swift-evolution 
> > > 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 

Re: [swift-evolution] [Proposal] Lexical scope statement (with .. do)

[Taras Zakharko via swift-evolution]

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 
>  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 
>  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 > > 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 
>> > 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/ 
>>> 
>>> 
>>> 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 
 > wrote:
 
 Hi,
 
 Please find my comment in body:
 
 BR,
 Radek Smogura
> On 27 Dec 2015, at 22:08, Taras Zakharko  > wrote:
> 
> 
>> On 27 Dec 2015, at 21:55, Mosab Elagha > > 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 
>> > wrote:
>> Hi,
>> 
>> That’s a great idea!
>> 
>> Kind regards,
>> Radek
>> 
>> > On 27 Dec 2015, at 21:10, Taras Zakharko via swift-evolution 
>> > > 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 

Re: [swift-evolution] [Proposal] Lexical scope statement (with .. do)

[Taras Zakharko via swift-evolution]

Same is true for the implicit self, and yet we’ve seen how people react to 
making self explicit. There are many places in contemporary Apple programming 
where this could be of great utility. For instance, I miss a lexical scope 
construction every time I work with Metal. 


> On 28 Dec 2015, at 02:24, Howard Lovatt via swift-evolution 
>  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 
> > 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/ 
>> 
>> 
>> 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 
>>> > wrote:
>>> 
>>> Hi,
>>> 
>>> Please find my comment in body:
>>> 
>>> BR,
>>> Radek Smogura
 On 27 Dec 2015, at 22:08, Taras Zakharko > wrote:
 
 
> On 27 Dec 2015, at 21:55, Mosab Elagha  > 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 
> > wrote:
> Hi,
> 
> That’s a great idea!
> 
> Kind regards,
> Radek
> 
> > On 27 Dec 2015, at 21:10, Taras Zakharko via swift-evolution 
> > > 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 

Re: [swift-evolution] [Proposal] Lexical scope statement (with .. do)

[Erica Sadun via swift-evolution]

I think it would be of great value to post both here and at the bug itself.

Thanks! -- E, looking forward to it


> On Dec 27, 2015, at 8:22 PM, Taras Zakharko  
> wrote:
> 
> 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 
>> > 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 
>>  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 >> > 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 
>>> > 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/ 
 
 
 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 
> > wrote:
> 
> Hi,
> 
> Please find my comment in body:
> 
> BR,
> Radek Smogura
>> On 27 Dec 2015, at 22:08, Taras Zakharko > > wrote:
>> 
>> 
>>> On 27 Dec 2015, at 21:55, Mosab Elagha >> > 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 
>>> > wrote:
>>> Hi,
>>> 
>>> That’s a great idea!
>>> 
>>> Kind regards,
>>> Radek
>>> 
>>> > On 27 Dec 2015, at 21:10, Taras Zakharko via swift-evolution 
>>> > > 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
>>> > {
>>> >