[swift-evolution] 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:

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

>
> On 13.04.2016 18:09, Radosław Pietruszewski wrote:
>
>> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160414/976e241d/attachment.html>