What about a VBA style with Statement?

[Jonathan_Tang]

Very strong -1 to implicit 'with'. Javascript tried this and it was a
disaster, and eventually banned in strict mode. It tends to make
compilation and optimization of a variable within a 'with' block
impossible, as it could refer to the fields of any object, or even a method
call behind protocol accessors. It also made it very difficult to
understand code, as you had to inspect values with a debugger before you
could grok the meaning of a simple variable reference.

Explicit 'with' is intriguing - it avoids a number of these pitfalls. But
the syntax suggested conflicts with that used for enums and static member
access. Right now, '.foo' is shorthand for 'Type.foo', where Type is the
inferred type of the expression. With the proposed syntax, would it
instead refer to the member of the 'with' referend? From the proposed
example, it looks like it:

with textLabel{
  .textAlignment = .Left
  .textColor = UIColor.darkTextColor()
  .font = UIFont.systemFontOfSize(15)
}

Note that UIColor and UIFont have to be explicit here. That's not really
an improvement in verbosity on how you'd write it now:

textLabel.textAlignment = .Left
textLabel.textColor = .darkTextColor()
textLabel.font = .systemFontOfSize(15)

Ultimately, I think I'm +1 for the library solution, where NSObject (is
there any way to extend all *Swift* objects, so they don't need the
Objective-C runtime?) gets a new method:

let textLabel = UILabel().with {
  $0.textAlignment = .Left
  $0.textColor = .darkTextColor()
  $0.font = .systemFontOfSize(15)
}

Also, on a philosophical note:

I’m -1, at least in the foreseeable future. I do agree that this is a
useful construct, but if I can do it in library code, paying only a small
price for this, I’d prefer Swift to grow better in places that a library
*can’t* fix.

Well, there a lot of things that *your personal* library can fix for you.
Should we stop improve the language and start to write just personal libs
with improvements?

Yes, absolutely. At least until your personal lib has gotten some
widespread adoption and people have had a chance to hack with it for a
while. Perhaps we need better tools for sharing, distributing, and
integrating utility libs (SwiftPM is coming!), but I feel strongly that
this is a better development methodology than including every imaginable
feature in the language itself.

The problem is that nearly all language features have unintended corner
cases, unintended consequences on development, and impedance mismatches
with existing language features. You can't predict what these will be
until you've written a bunch of *actual code* using them, in the target
language. When it's your personal lib, you can iterate on this nearly
instantaneously. When it's a language spec, every change requires long
consensus discussions, and you can't back out previous changes that people
are relying on.

···

On Wed, Apr 13, 2016 at 9:54 AM, Vladimir.S via swift-evolution < swift-evolution@swift.org> wrote:

On 13.04.2016 18:09, Radosław Pietruszewski wrote:

[Milos_Rankovic1 (Milos Rankovic)]

Whilst I would not mind the `with` pattern, it’s worth noting that Swift already has some very fine alternatives:

  let questionLabel: UILabel = {
    let $ = UILabel()
    $.textAlignment = .Center
    $.font = UIFont(name:"DnealianManuscript", size: 72)
    $.text = "?"
    $.numberOfLines = 0
    return $
  }()

Including some lazy options:
  
  private(set) lazy var questionLabel: UILabel = { ... }()
  
  static let questionLabel: UILabel = { ... }()

milos

···

On 13 Apr 2016, at 17:04, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

The biggest advantage of the with pattern IMO is Cocoa initializers. It provides a more unified
initialization scope. Instead of:

let questionLabel = UILabel()
questionLabel.textAlignment = .Center
questionLabel.font = UIFont(name:"DnealianManuscript", size: 72)
questionLabel.text = currentQuestion.text
questionLabel.numberOfLines = 0

[Joanna_Carter]

As much as I detested the 'with' construct in Delphi, with all its accompanying opportunities for errors of scope, if you really think it a good idea, then you need to consider the possibility of those who want to 'with' more than one target. In which case, the use of $0, $1, etc would seem logical, although not necessarily very readable.

Joanna

···

--
Joanna Carter
Carter Consulting

(de mon iPhone)

[VladimirS (Vladimir)]

As much as I detested the 'with' construct in Delphi, with all its

accompanying opportunities for errors of scope, if you really think it a good idea, then you need to consider the possibility of those who want to 'with' more than one target. In which case, the use of $0, $1, etc would seem logical, although not necessarily very readable.
>
> Joanna
>
> --
> Joanna Carter
> Carter Consulting
>
> (de mon iPhone)
>

Actually we can "manually" now implement the very clean and handy "with" (including with more than 1 "target") like this:

(I propose to include such kind of "with" feature to language or to standard classes/protocols to be able to use it out-of-box for any class/structure, not for some we have to apply manually)

class A {
     var x = 0
     var y = 0
     var z = 0

     func with(block: (this: A)->()) -> Self {
         block(this: self)

         return self
     }

     func with<T>(another: T, block: (this: A, that: T)->()) -> Self {
         block(this: self, that: another)

         return self
     }
}

var myFirstVeryLongInstanceName = A().with {
     $0.x = 1
     $0.y = 2
     $0.z = 3
}

var mySecondVeryLongInstanceName = A().with {new in
     new.x = 11
     new.y = 12
     new.z = 13
}

myFirstVeryLongInstanceName.with {my in
     my.x *= 1
     my.y *= 2
     my.z *= 3
}

mySecondVeryLongInstanceName.with(myFirstVeryLongInstanceName) {to, from in
     to.x = from.x * 10
     to.y = from.y * 20
     to.z = from.z * 30

     print(from.x)
     print(to.x)
}

mySecondVeryLongInstanceName.with(myFirstVeryLongInstanceName) {
     $0.x = $1.x * 100
     $0.y = $1.y * 200
     $0.z = $1.z * 300

     print($1.x)
     print($0.x)
}

···

On 22.04.2016 14:02, Joanna Carter wrote:

[VladimirS (Vladimir)]

@Thorsten, thank you for providing these functions and sample code.
Unfortunately personally I can't check them now to find out if there is some problems with them. (But will check later)

In any case. Let's assume these functions are 100% fine and can be used in almost any situation with no drawbacks.

Do you(and all other) agree that such functions should be a part of standard library, so we'll have this "with" feature out-of-box with correct implementation (and so there will be no need to re-invent them for many of us and to re-copy into each project) ?

This is the main first question regarding this proposal.

···

On 23.04.2016 14:28, Thorsten Seitz wrote:

Note that function like this :
func with<T>(item:T, apply:(T)->Void) { apply(item) }

Produces such kind of problems:
struct A {var x = 1}
let a1 = A() // constant
with (a1) { $0.x = 10 } // this will be compiled without errors/warnings

This works as expected (giving a compile error for let constant):

// for value types
funcwith<T>(inoutitem: T, apply: (inoutT) throws-> Void) rethrows-> Void{
    tryapply(&item)
}

// for reference types (classes)
funcwith<T: AnyObject>(item: T, apply: (T) throws-> Void) rethrows-> T{
    tryapply(item)
    returnitem
}

// value types

structA { varx = 1}

vara1 = A()
with(&a1) {
    $0.x= 10
}
print(a1) // A(x: 10)

/*
let a2 = A()
with (&a2) { // error: cannot pass immutable value as inout argument: 'a2'
is a 'let' constant
    $0.x = 10
}
print(a2)
*/

// reference types (classes)

classB : CustomDebugStringConvertible{
    vary = 1
    vardebugDescription: String{ return"B(y: \(y))"}
}

varb1 = B()
with(b1) {
    $0.y= 11
}
print(b1) // B(y: 11)

// reference types allow this pattern (value types don't)
letb2 = with(B()) {
    $0.y= 12
}
print(b2) // B(y: 12)

-Thorsten

Am 22.04.2016 um 09:18 schrieb Vladimir.S via swift-evolution
<swift-evolution@swift.org <mailto:swift-evolution@swift.org>>:

Just wanted to summarize our opinions on this suggestion that we was
discussing earlier and check if someone is ready to crate an "official"
proposal for this feature.

There a number of questions regarding this feature we can discuss, for
example statement vs method, what could be a placeholder of target
instance inside the scope($0, $, _, .., nothing etc)

The main question, *do you support that we need "with" feature in some
way in Swift 3.0 out of the box* . And if so, what variant do you prefer.

* this proposal is for *explicit* "with", where it is clear what
method/property belongs to the "target" instance
* I believe that as such feature is really useful and handy, if it is
explicit and if it is clearly showing in code what we are doing - we want
to have this feature as part of language/standard lib rather than
possibility to use some workaround to implement it
* It is not about saving the space in code. It is about more readable and
(I insist) more stable(with less errors) code. Much less possibilities
for copy-paste errors. Wrong code completion suggestion(by editor) can
not produce error. It is explicit and clear, it has much less noise in code.
* Many of us already implemented and use such "with" construction in some way

There were 2 main suggestions :

1) Introduce "with" statement that can be used in for example in such way:

// set props just after creating
// similar to "if let.. " and "guard let.."
with let questionLabel = UILabel() {
//set props of created instance here
// here we can have:
// $0.prop = value
// or
// ..prop = value
// or
// .prop = value
// or
// _.prop = value
// or
// $.prop = value
// or ?
}
// questionLabel is available here

// works for structures
with var some = SomeStruct() {
//...
}

// just for some class/structure/enum
with questionLabel {
// ..
}

probably

with var src = someNamedInstance1,
    let dst = someNamedInstance2 {
  src.propA = dst.propB
  dst.someMethod(src.propC)
  src.someMehtod()
}

or
with someNamedInstance1, someNamedInstance2 {
  $0.propA = $1.propB
  $1.someMethod($0.propC)
  $0.someMehtod()
}

2) Introduce .with method for each(?) class/struct, so we can use out-of-box:

let questionLabel = UILabel().with {
//set props of created instance here
$0.prop = value
}

var someStructInstance = SomeStruct().with {target in
target.prop = value
}

questionLabel.with {label in
label.prop = value
}

someNamedInstance1.with(someNamedInstance2) {src, dst in
  src.propA = dst.propB
  dst.someMethod(src.propC)
  src.someMehtod()
}

Note that function like this :
func with<T>(item:T, apply:(T)->Void) { apply(item) }

Produces such kind of problems:
struct A {var x = 1}
let a1 = A() // constant
with (a1) { $0.x = 10 } // this will be compiled without errors/warnings

On 13.04.2016 17:17, Radosław Pietruszewski via swift-evolution wrote:

It can be (more-or-less) solved in library code today:

   extension NSObjectProtocol {
       public func with(@noescape fn: Self -> Void) -> Self {
           fn(self)
           return self
       }
   }

This way, you can do, on NSObjects:

   textLabel.with {

   $0.textAlignment = .Left

   $0.textColor = .darkTextColor()

   }

I love this pattern.

You can also make it a function to make it work with any value of any kind
(it will then take form of `with(foo) { …}`).

Ideally, if you could write a universal extension (something like
`extension Any`), you could just add this behavior, with method syntax, to
everything.

— Radek

On 13 Apr 2016, at 15:15, 李海珍 via swift-evolution >>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>> <mailto:swift-evolution@swift.org>> wrote:

I recently learned some VBA and I found a very conveniently `with`
statement.

`with` statement can be helpful to set property for UIKit instance.

for instance a UILabel instance `textLabel` ,with `with` statement we can
set UILabel property like this

with textLabel{

.textAlignment= .Left

.textColor= UIColor.darkTextColor()

.font= UIFont.systemFontOfSize(15)

}

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
<mailto:swift-evolution@swift.org>
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

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

[VladimirS (Vladimir)]

Agree, that we can already use some hacks(IMO) to have some kind of what we need.
Actually, we already discussed some variants : method "with" in extension to type and global generic function "with". Each of them has disadvantages in compare to "with" language construction. In your example you need to create temp instance, need "return", calls the block() - many noise for simple action.

Also, such workarounds not always protect us from problems(like modifying constant struct instance in generic "with" method - it compiles. but raise runtime error) and each of us needs to move these workarounds from project to project, plus we use different implementation for the "with" feature, no standard, in one project with many developers we'll find different variants for the same "with" feature.

I believe we need such language construction in some or another implementation.

I suggest these constructions:

// similar to "if let.. " and "guard let.."
with let questionLabel = UILabel() {
   //...
}

with var some = SomeStruct() {
   //...
}

with questionLabel {
   // ..
}

And suggest to discuss these variants:

"one-point" (my preffered) :

with questionLabel {
   .textAlignment = .Center
   .font = UIFont(name:"DnealianManuscript", size: 72)
   .text = "?"
   .numberOfLines = 0
}

"two points":

with questionLabel {
   ..textAlignment = .Center
   ..font = UIFont(name:"DnealianManuscript", size: 72)
   ..text = "?"
   ..numberOfLines = 0
}

"$" sign :

with questionLabel {
   $.textAlignment = .Center
   $.font = UIFont(name:"DnealianManuscript", size: 72)
   $.text = "?"
   $.numberOfLines = 0
}

"$0" (don't think this is good, as there can not be $1 etc):

with questionLabel {
   $0.textAlignment = .Center
   $0.font = UIFont(name:"DnealianManuscript", size: 72)
   $0.text = "?"
   $0.numberOfLines = 0
}

Opinions?

···

On 14.04.2016 13:41, Milos Rankovic via swift-evolution wrote:

On 13 Apr 2016, at 17:04, Erica Sadun via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

The biggest advantage of thewithpattern IMO is Cocoa initializers. It
provides a more unified
initialization scope. Instead of:

letquestionLabel =UILabel()
questionLabel.textAlignment= .Center
questionLabel.font= UIFont(name:"DnealianManuscript", size:72)
questionLabel.text=currentQuestion.text
questionLabel.numberOfLines=0

Whilst I would not mind the `with` pattern, it’s worth noting that Swift
already has some very fine alternatives:

letquestionLabel: UILabel= {
let$ = UILabel()
$.textAlignment= .Center
$.font= UIFont(name:"DnealianManuscript", size: 72)
$.text= "?"
$.numberOfLines= 0
return$
}()

Including some lazy options:

private(set)lazyvarquestionLabel: UILabel= {...}()

staticletquestionLabel: UILabel= {...}()

milos

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

[L_Mihalkovic]

For what it's worth, I left vba behind a long time ago and I have some bad memories of what I saw in these with blocks: people writing a page worth of code where only a couple line were actually referencing .xxxxx. In the end, they thought it made their code look cool when I just saw it as a readability nightmare.
IMHO a good language is a mix between coolness and restraint, such that the worse things the worst programmers will do cannot FAR outweigh the good the fewer disciplined programmers will write. Leaving this feature in the realm of libraries will mandate that teams discuss the topic, and choose the pattern they want to buy into. Putting it into the language will IMHO result in a lot more anything-goes, on account of "well it was there, so they want us to use it, right?!"

Cheers
(From mobile)

···

On Apr 14, 2016, at 3:49 PM, Vladimir.S via swift-evolution <swift-evolution@swift.org> wrote:

Agree, that we can already use some hacks(IMO) to have some kind of what we need.
Actually, we already discussed some variants : method "with" in extension to type and global generic function "with". Each of them has disadvantages in compare to "with" language construction. In your example you need to create temp instance, need "return", calls the block() - many noise for simple action.

Also, such workarounds not always protect us from problems(like modifying constant struct instance in generic "with" method - it compiles. but raise runtime error) and each of us needs to move these workarounds from project to project, plus we use different implementation for the "with" feature, no standard, in one project with many developers we'll find different variants for the same "with" feature.

I believe we need such language construction in some or another implementation.

I suggest these constructions:

// similar to "if let.. " and "guard let.."
with let questionLabel = UILabel() {
//...
}

with var some = SomeStruct() {
//...
}

with questionLabel {
// ..
}

And suggest to discuss these variants:

"one-point" (my preffered) :

with questionLabel {
.textAlignment = .Center
.font = UIFont(name:"DnealianManuscript", size: 72)
.text = "?"
.numberOfLines = 0
}

"two points":

with questionLabel {
..textAlignment = .Center
..font = UIFont(name:"DnealianManuscript", size: 72)
..text = "?"
..numberOfLines = 0
}

"$" sign :

with questionLabel {
$.textAlignment = .Center
$.font = UIFont(name:"DnealianManuscript", size: 72)
$.text = "?"
$.numberOfLines = 0
}

"$0" (don't think this is good, as there can not be $1 etc):

with questionLabel {
$0.textAlignment = .Center
$0.font = UIFont(name:"DnealianManuscript", size: 72)
$0.text = "?"
$0.numberOfLines = 0
}

Opinions?

On 14.04.2016 13:41, Milos Rankovic via swift-evolution wrote:

On 13 Apr 2016, at 17:04, Erica Sadun via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

The biggest advantage of thewithpattern IMO is Cocoa initializers. It
provides a more unified
initialization scope. Instead of:

letquestionLabel =UILabel()
questionLabel.textAlignment= .Center
questionLabel.font= UIFont(name:"DnealianManuscript", size:72)
questionLabel.text=currentQuestion.text
questionLabel.numberOfLines=0

Whilst I would not mind the `with` pattern, it’s worth noting that Swift
already has some very fine alternatives:

letquestionLabel: UILabel= {
let$ = UILabel()
$.textAlignment= .Center
$.font= UIFont(name:"DnealianManuscript", size: 72)
$.text= "?"
$.numberOfLines= 0
return$
}()

Including some lazy options:

private(set)lazyvarquestionLabel: UILabel= {...}()

staticletquestionLabel: UILabel= {...}()

milos

_______________________________________________
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

[Dany_St-Amant]

Agree, that we can already use some hacks(IMO) to have some kind of what we need.
Actually, we already discussed some variants : method "with" in extension to type and global generic function "with". Each of them has disadvantages in compare to "with" language construction. In your example you need to create temp instance, need "return", calls the block() - many noise for simple action.

Also, such workarounds not always protect us from problems(like modifying constant struct instance in generic "with" method - it compiles. but raise runtime error) and each of us needs to move these workarounds from project to project, plus we use different implementation for the "with" feature, no standard, in one project with many developers we'll find different variants for the same "with" feature.

I believe we need such language construction in some or another implementation.

I suggest these constructions:

// similar to "if let.. " and "guard let.."
with let questionLabel = UILabel() {
//...
}

with var some = SomeStruct() {
//...
}

with questionLabel {
// ..
}

And suggest to discuss these variants:

"one-point" (my preffered) :

with questionLabel {
.textAlignment = .Center
.font = UIFont(name:"DnealianManuscript", size: 72)
.text = "?"
.numberOfLines = 0
}

"two points":

with questionLabel {
..textAlignment = .Center
..font = UIFont(name:"DnealianManuscript", size: 72)
..text = "?"
..numberOfLines = 0
}

"$" sign :

with questionLabel {
$.textAlignment = .Center
$.font = UIFont(name:"DnealianManuscript", size: 72)
$.text = "?"
$.numberOfLines = 0
}

"$0" (don't think this is good, as there can not be $1 etc):

with questionLabel {
$0.textAlignment = .Center
$0.font = UIFont(name:"DnealianManuscript", size: 72)
$0.text = "?"
$0.numberOfLines = 0
}

Thought with a free standing 'with' the next request to come in, could be to be able to do something like:

with source, destination {
  $1.something = $0.somethingSimilar
  $1.x = $0.bound.left
  $1.y = $0.point.top
}

So using $0, may be a future proofing option.

Dany

···

Le 14 avr. 2016 à 09:49, Vladimir.S via swift-evolution <swift-evolution@swift.org> a écrit :

On 14.04.2016 13:41, Milos Rankovic via swift-evolution wrote:

On 13 Apr 2016, at 17:04, Erica Sadun via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

The biggest advantage of thewithpattern IMO is Cocoa initializers. It
provides a more unified
initialization scope. Instead of:

letquestionLabel =UILabel()
questionLabel.textAlignment= .Center
questionLabel.font= UIFont(name:"DnealianManuscript", size:72)
questionLabel.text=currentQuestion.text
questionLabel.numberOfLines=0

Whilst I would not mind the `with` pattern, it’s worth noting that Swift
already has some very fine alternatives:

letquestionLabel: UILabel= {
let$ = UILabel()
$.textAlignment= .Center
$.font= UIFont(name:"DnealianManuscript", size: 72)
$.text= "?"
$.numberOfLines= 0
return$
}()

Including some lazy options:

private(set)lazyvarquestionLabel: UILabel= {...}()

staticletquestionLabel: UILabel= {...}()

milos

_______________________________________________
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

[VladimirS (Vladimir)]

Can't agree with you.

As you see from this topic, many of us use the "with" feature by
using workarounds/hacks.

Those, who don't use such "with" feature - can
produce even more bugging code(copy-paste,wrong editor's code completion
suggestion).
So, I think this is "good" feature, not just cool/nice
looking. It will help us to write code with less bugs, without workarounds/hacks.

Do you want to stop good feature, that is helping us to produce good code, because someone can use it "wrong"? Well, don't think this is right.

(Sorry for duplicate)

···

On 14.04.2016 19:35, L. Mihalkovic wrote:
> For what it's worth, I left vba behind a long time ago and I have some
> bad memories of what I saw in these with blocks: people writing a page
> worth of code where only a couple line were actually referencing .xxxxx.
> In the end, they thought it made their code look cool when I just saw it
> as a readability nightmare. IMHO a good language is a mix between
> coolness and restraint, such that the worse things the worst programmers
> will do cannot FAR outweigh the good the fewer disciplined programmers
> will write. Leaving this feature in the realm of libraries will mandate
> that teams discuss the topic, and choose the pattern they want to buy
> into. Putting it into the language will IMHO result in a lot more
> anything-goes, on account of "well it was there, so they want us to use
> it, right?!"
>
> Cheers (From mobile)
>
>> On Apr 14, 2016, at 3:49 PM, Vladimir.S via swift-evolution >> <swift-evolution@swift.org> wrote:
>>
>> Agree, that we can already use some hacks(IMO) to have some kind of
>> what we need. Actually, we already discussed some variants : method
>> "with" in extension to type and global generic function "with". Each
>> of them has disadvantages in compare to "with" language construction.
>> In your example you need to create temp instance, need "return", calls
>> the block() - many noise for simple action.
>>
>> Also, such workarounds not always protect us from problems(like
>> modifying constant struct instance in generic "with" method - it
>> compiles. but raise runtime error) and each of us needs to move these
>> workarounds from project to project, plus we use different
>> implementation for the "with" feature, no standard, in one project
>> with many developers we'll find different variants for the same "with"
>> feature.
>>
>> I believe we need such language construction in some or another
>> implementation.
>>
>> I suggest these constructions:
>>
>> // similar to "if let.. " and "guard let.." with let questionLabel =
>> UILabel() { //... }
>>
>> with var some = SomeStruct() { //... }
>>
>> with questionLabel { // .. }
>>
>> And suggest to discuss these variants:
>>
>> "one-point" (my preffered) :
>>
>> with questionLabel { .textAlignment = .Center .font =
>> UIFont(name:"DnealianManuscript", size: 72) .text = "?" .numberOfLines
>> = 0 }
>>
>> "two points":
>>
>> with questionLabel { ..textAlignment = .Center ..font =
>> UIFont(name:"DnealianManuscript", size: 72) ..text = "?"
>> ..numberOfLines = 0 }
>>
>> "$" sign :
>>
>> with questionLabel { $.textAlignment = .Center $.font =
>> UIFont(name:"DnealianManuscript", size: 72) $.text = "?"
>> $.numberOfLines = 0 }
>>
>> "$0" (don't think this is good, as there can not be $1 etc):
>>
>> with questionLabel { $0.textAlignment = .Center $0.font =
>> UIFont(name:"DnealianManuscript", size: 72) $0.text = "?"
>> $0.numberOfLines = 0 }
>>
>> Opinions?
>>
>> On 14.04.2016 13:41, Milos Rankovic via swift-evolution wrote:
>>>> On 13 Apr 2016, at 17:04, Erica Sadun via swift-evolution >>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> >>>> wrote:
>>>>
>>>> The biggest advantage of thewithpattern IMO is Cocoa initializers.
>>>> It provides a more unified initialization scope. Instead of:
>>>>
>>>> letquestionLabel =UILabel() questionLabel.textAlignment= .Center
>>>> questionLabel.font= UIFont(name:"DnealianManuscript", size:72)
>>>> questionLabel.text=currentQuestion.text
>>>> questionLabel.numberOfLines=0
>>>
>>> Whilst I would not mind the `with` pattern, it’s worth noting that
>>> Swift already has some very fine alternatives:
>>>
>>> letquestionLabel: UILabel= { let$ = UILabel() $.textAlignment=
>>> .Center $.font= UIFont(name:"DnealianManuscript", size: 72) $.text=
>>> "?" $.numberOfLines= 0 return$ }()
>>>
>>> Including some lazy options:
>>>
>>> private(set)lazyvarquestionLabel: UILabel= {...}()
>>>
>>> staticletquestionLabel: UILabel= {...}()
>>>
>>> milos
>>>
>>> _______________________________________________ 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
> .
>

[VladimirS (Vladimir)]

Agree. Such construction is also very useful. +1 to implement it.

From one side we know, that we should name variables with meaningful names. From other side, the longer the name of variable - the more noise you see in code and in some cases this noise,copy-paste,ide completion suggestions produce bugs in code when you need a lot of assignments/actions for one/two particular instance(s).
So IMO such "with" produces less errors and is clear.

Please provide your opinions on this.

···

On 15.04.2016 3:47, Dany St-Amant via swift-evolution wrote:

Thought with a free standing 'with' the next request to come in, could be to be able to do something like:

with source, destination {
  $1.something = $0.somethingSimilar
  $1.x = $0.bound.left
  $1.y = $0.point.top
}

So using $0, may be a future proofing option.

Dany

[L_Mihalkovic]

that is a bit of an extreme simplification of what I was saying, but I do believe that programming has become a modern day blue-colar job where IMHO the majority of programmers display a lot of creativity when it comes to perverting good ideas. In that context, I think that it makes sense to rescue code from the programmers writing it. I have seen a lot of bad VBA code written using WITH blocks.

I just realized that my problem with this thread is the reference to VBA. The concept of method cascades described in: Swift Cascading.md · GitHub is partially interesting to me.

IMHO a solution allowing the following

WITH self {

  .doSomething()

  // a lot of code
  …
  ….
  …..
  
  // and 700 lines of code later
  .doSeomthingElse()

}

is barking up the wrong tree, because for as grotesque as this code is, if it can be done, it will be done… a lot .. because it is easy to do. And code like the following is IMHO taking the same slippery slope

          sharedName = newValue // myInstance.sharedName = newValue (3)
          _.sharedName = newValue // the locally scoped newValue (2)
          _._.sharedName = newValue // I don't actually propose this, but (1)

The following code however looks like a real productivity improvement (provided NOTHING else can be added between the chained invocations)

with let task = NSTask() {
    launchPath = "/usr/bin/mdfind"
    arguments = ["kMDItemDisplayName == *.playground"]
    standardOutput = pipe
    launch()
    waitUntilExit()
}

Cheers
LM/

···

On Apr 14, 2016, at 7:39 PM, Vladimir.S via swift-evolution <swift-evolution@swift.org> wrote:

Can't agree with you.

As you see from this topic, many of us use the "with" feature by
using workarounds/hacks.

Those, who don't use such "with" feature - can
produce even more bugging code(copy-paste,wrong editor's code completion
suggestion).
So, I think this is "good" feature, not just cool/nice
looking. It will help us to write code with less bugs, without workarounds/hacks.

Do you want to stop good feature, that is helping us to produce good code, because someone can use it "wrong"? Well, don't think this is right.