Revisiting 0004 etc. - Swift deprecations


(John Heerema) #1

Warning - long post.
I know that some folks really hate long posts, so let me apologize right
now for this being a long post. Please feel free to skip right on past it.
I posted it on a weekend, when there¹s less mailing list traffic, but that
doesn¹t make it any shorter.

Warning - revisits two approved deprecations.
If you really, really hate it when people want to revisit decisions that
have already been made, please just skip right past this post. My
apologies for not contributing to the discussion when these decisions were
originally being made!

The day that Swift was announced at the WWDC was very
exciting for me, and I immediately read the Swift book from beginning to
end.
Swift quickly became my favourite language: I felt that the Swift language
developers had created a beautiful language that combined expressiveness
with
practicality in a way that made Swift code both powerful and easy to
understand. Swift was crafted by some very smart and practical people.

To put my thoughts into perspective, I should mention that
I¹ve taught Computer Science at a senior University level for years, and
have
worked in industry for decades. As a computer scientist, I¹ve had a strong
interest in computer languages for many years. I became an Apple developer
upon
purchasing an Apple Lisa a very long time ago.

Over the past couple of years though, I¹ve seen what I think
of as a growing emphasis on strict feature orthagonality at the expense of
practicality in Swift. Perhaps this because much of the feedback on the
language has been provided by those of us who are interested in computer
languages. But for whatever reasons, the Swift language seems to have
become
more cluttered and less friendly.

As I¹ve gone through the various beta releases, I¹ve seen
changes that detract from the experience of using Swift, for reasons that
seem
related to ³language purity².

I was finally moved to try to express my thoughts after
seeing a couple of what I think of as particularly inadvisable proposals
for
Swift version 3 and beyond.

Unary increment and decrement operators: ++ and ‹

The first of these was the now approved removal of Swift¹s
convenient unary increment and decrement operators. I would agree with
some of
the comments that have been made about these operators not being quite
orthogonal with other expressive elements in the language. Nonetheless,
they
are a handy and popular way to iterate over enumerable collections, and to
increment and decrement a variable that is used for purposes other than
iteration. They also lend themselves to being extended to other data
types, such
as position pointers in linked lists, where they can implement the
convenient
concept of ³the next thing² (which += does not provide).

The desire to get rid of these rather harmless operators
reminds me of some of Apple¹s own history, and the history of computer
languages in general. Niklaus Wirth didn¹t care for shortcut operators
either,
and so Pascal never got them.

However, Apple eventually moved away from Pascal to C, even
though C is in many ways a deeply flawed language that is responsible for a
wide litany of software errors. Why? I personally really liked Pascal, but
many
(most) developers didn¹t care for the language. I¹d argue that developers
preferred the flexibility of C to what they saw as the overly restricting
constraints of Pascal.

One of the surprising reasons that I heard a lot at the
time, was that developers didn¹t want to lose C¹s shortcut operators. If
Wirth
had been willing to give Pascal some of C¹s convenience operators, things
might
well have turned out differently. Developers hate typing.

The notion that there should be exactly one way to do a
particular thing sounds like dogma to me: not practicality. If people are
concerned that unary operators confuse beginners, I would encourage them to
convince educators not to teach them to beginners. Anyway, there are a lot
of
things in Swift that can confuse beginners!

Although it¹s hard for me to believe that having these
operators return void has been seriously considered, I would argue that
this
would be even sillier than removing them. A lot of developers use both C
(or
Objective C, C++, C#, Java, etc. etc.) and Swift ­ having those unary
operators
act completely differently in Swift would be a great way to alienate those
developers.

Let¹s not forget that Swift
is not the lingua franca of the computing world. It¹s an upstart that
needs to
attract the development community. Why repel people coming from the various
C-like languages without a really, really, convincingly good reason? it¹s
better for an upstart to attract than to repel.

Right now, there are an awful lot of developers who are used
to, and like the convenience of unary increment and decrement operators.
Removing them seems bound to annoy developers and diminish the popularity
of
Swift, in exchange for Š well, not very much except for a tiny bit of
language
purity. That just seems silly to me.

C-style For loops

Removal of C-style For loops has already been approved for a
future version of Swift. Even though I find the C-style For loop to be a
bit
ugly and unintuitive, I believe that removing it was the wrong thing to do.

It comes down to flexibility and expressiveness. The reality
is that C-style For loops easily implement certain operations that are more
difficult to implement without them.

I¹ve seen comments that C-style For loops are ³hardly ever
used², and that ³hardly any² algorithms really need them. I believe that
³hardly any² is a lazy mental shortcut for ³Well, I don¹t like them, and I
I
don¹t use them, so I don¹t think that any anyone who¹s important uses
them.².

Yes, there are many cases in which I believe that Swift
provides looping structures that are safer and easier to understand than
the
C-style For loop. I¹d even say most cases. But I work in the scientific and
engineering domains, and can point to many instances of looping structures
that
are easily expressed with a C-style For loop, but are clumsy to implement
without it.

In the world of the natural sciences, there are any number
of instances of loop increments that requires some kind of a calculation.
There
are any number of instances of dynamically calculated loop termination.

Swift¹s stride has some nice features for simple increments,
but also has some important limitations. Among them, it involves the two
step
process of first creating an enumerable set, and then iterating over it.
In the
natural sciences, it is not uncommon for complex loop increments to be
used in
loops that are executed millions of times.

Conceptually, creating an enumerable set, and then iterating over it,
reeks of the arrogance of assuming that computing resources are unlimited.
Even
though the compiler may optimize the stride into the loop structure, it
feels
like unnecessarily creating a gigantic enumerable set.

Whether we like it or not, the enduring popularity of the
C-style For loop comes from it¹s flexibility. Swift doesn¹t have a better
alternative that also provides the same flexibility. So don¹t take it
away. If
you don¹t like it (I don¹t always either), think of something that is
clearly
superior in 100% of use cases. Even then, I would argue against removing
it.

I would argue that the C-style For loop implements some
rather Swift-like concepts. The syntax provide for three closures: one
each for
(a) things to do first, (b) things to do when deciding whether to stop
iterating, and (c) things to do after each iteration. How is that contrary
to the principals of Swift?

Just like pretty much everywhere that Swift allows closures,
they can be used to write code that is difficult to understand. But the
syntax
is general and flexible enough to have survived intact for half a century.

It¹s the carrot vs. the stick. Developers prefer the carrot.
The belief that we can force developers to write better code by taking away
language features, has not historically met with success. Let me say that
again, because I think it¹s important. Developers who are given a choice
between C and a ³better² language (say Modula-2, or Swift) are unlikely to
react favourably to being told ³we¹re taking away this feature of C that
you
like, for your own good, because you¹re too stupid to use it sensibly².
Taking away well-understood expressive language elements, and replacing
them with something less expressive, is not going to win developers over.

C-style For loops haven¹t changed in half acentury, because they work.
A lot of other languages have also adopted them, because they work.

If I may, I¹d like to take the English language by way of
analogy. English contains a lot of weird, irregular language elements.
There¹s
no single way to express a concept. Instead, there are many, subtly
different
ways to express yourself.

But, for all of its weirdness, English has remained popular
for centuries, whereas more ³sensible², ³regular² languages like Esperanto
never caught on. The reasons are flexibility and expressiveness. The same
thing
applies to computer languages.

If we only look inside the world of compilers and computer
science instruction, to see if we need the flexibility of C-style For
loops, we
might mistakenly think that we don¹t. But those domains are relatively
simple
in comparison to the physical sciences. Our experience there doesn¹t always
translate to the more complex world of physical reality. So let¹s not throw
away convenient and useful language features just because we don¹t
personally
care for them.

Don¹t make Swift Yet Another Interesting Experiment in
language design that wasn¹t widely adopted, and
ended up being relegated to the dustbin of history.
It would make me sad to see the best new computer language
in ages become just another niche language. We already
have enough of those.

So, all of you folks who voted to remove these things, please don¹t hate
me!

Regards,
J. Heerema, Ph.D.

default.xml (3.15 KB)

default.xml (3.15 KB)


(Ross O'Brien) #2

Because you're coming to the discussion late, the arguments you're making
are a little out of date. It's no longer a case of not removing these
features. It's now a case of having a compelling reason to put them back.

I trust you've read the proposals that were put forward. For the benefit of
those reading, they're here:
https://github.com/apple/swift-evolution/blob/master/proposals/0004-remove-pre-post-inc-decrement.md
https://github.com/apple/swift-evolution/blob/master/proposals/0007-remove-c-style-for-loops.md

There are several disadvantages listed for keeping these two features.
Those are the arguments you need to counter. As it happens, both proposals
refer to the metric of 'if this wasn't already in Swift, would it be
accepted for Swift 3?' and both features have been deemed to fail this
criterion. That's what you need to address.

Bear in mind these decisions were made several months ago, and both
features have already been deprecated as of Swift 2.2, which is now in use
in production code, many developers (including myself) are already
refactoring their code to remove uses of these syntax forms.

···

On Sun, Apr 3, 2016 at 12:45 AM, John Heerema via swift-evolution < swift-evolution@swift.org> wrote:

Warning - long post.
I know that some folks really hate long posts, so let me apologize right
now for this being a long post. Please feel free to skip right on past it.
I posted it on a weekend, when there¹s less mailing list traffic, but that
doesn¹t make it any shorter.

Warning - revisits two approved deprecations.
If you really, really hate it when people want to revisit decisions that
have already been made, please just skip right past this post. My
apologies for not contributing to the discussion when these decisions were
originally being made!

The day that Swift was announced at the WWDC was very
exciting for me, and I immediately read the Swift book from beginning to
end.
Swift quickly became my favourite language: I felt that the Swift language
developers had created a beautiful language that combined expressiveness
with
practicality in a way that made Swift code both powerful and easy to
understand. Swift was crafted by some very smart and practical people.

To put my thoughts into perspective, I should mention that
I¹ve taught Computer Science at a senior University level for years, and
have
worked in industry for decades. As a computer scientist, I¹ve had a strong
interest in computer languages for many years. I became an Apple developer
upon
purchasing an Apple Lisa a very long time ago.

Over the past couple of years though, I¹ve seen what I think
of as a growing emphasis on strict feature orthagonality at the expense of
practicality in Swift. Perhaps this because much of the feedback on the
language has been provided by those of us who are interested in computer
languages. But for whatever reasons, the Swift language seems to have
become
more cluttered and less friendly.

As I¹ve gone through the various beta releases, I¹ve seen
changes that detract from the experience of using Swift, for reasons that
seem
related to ³language purity².

I was finally moved to try to express my thoughts after
seeing a couple of what I think of as particularly inadvisable proposals
for
Swift version 3 and beyond.

Unary increment and decrement operators: ++ and ‹

The first of these was the now approved removal of Swift¹s
convenient unary increment and decrement operators. I would agree with
some of
the comments that have been made about these operators not being quite
orthogonal with other expressive elements in the language. Nonetheless,
they
are a handy and popular way to iterate over enumerable collections, and to
increment and decrement a variable that is used for purposes other than
iteration. They also lend themselves to being extended to other data
types, such
as position pointers in linked lists, where they can implement the
convenient
concept of ³the next thing² (which += does not provide).

The desire to get rid of these rather harmless operators
reminds me of some of Apple¹s own history, and the history of computer
languages in general. Niklaus Wirth didn¹t care for shortcut operators
either,
and so Pascal never got them.

However, Apple eventually moved away from Pascal to C, even
though C is in many ways a deeply flawed language that is responsible for a
wide litany of software errors. Why? I personally really liked Pascal, but
many
(most) developers didn¹t care for the language. I¹d argue that developers
preferred the flexibility of C to what they saw as the overly restricting
constraints of Pascal.

One of the surprising reasons that I heard a lot at the
time, was that developers didn¹t want to lose C¹s shortcut operators. If
Wirth
had been willing to give Pascal some of C¹s convenience operators, things
might
well have turned out differently. Developers hate typing.

The notion that there should be exactly one way to do a
particular thing sounds like dogma to me: not practicality. If people are
concerned that unary operators confuse beginners, I would encourage them to
convince educators not to teach them to beginners. Anyway, there are a lot
of
things in Swift that can confuse beginners!

Although it¹s hard for me to believe that having these
operators return void has been seriously considered, I would argue that
this
would be even sillier than removing them. A lot of developers use both C
(or
Objective C, C++, C#, Java, etc. etc.) and Swift ­ having those unary
operators
act completely differently in Swift would be a great way to alienate those
developers.

Let¹s not forget that Swift
is not the lingua franca of the computing world. It¹s an upstart that
needs to
attract the development community. Why repel people coming from the various
C-like languages without a really, really, convincingly good reason? it¹s
better for an upstart to attract than to repel.

Right now, there are an awful lot of developers who are used
to, and like the convenience of unary increment and decrement operators.
Removing them seems bound to annoy developers and diminish the popularity
of
Swift, in exchange for Š well, not very much except for a tiny bit of
language
purity. That just seems silly to me.

C-style For loops

Removal of C-style For loops has already been approved for a
future version of Swift. Even though I find the C-style For loop to be a
bit
ugly and unintuitive, I believe that removing it was the wrong thing to do.

It comes down to flexibility and expressiveness. The reality
is that C-style For loops easily implement certain operations that are more
difficult to implement without them.

I¹ve seen comments that C-style For loops are ³hardly ever
used², and that ³hardly any² algorithms really need them. I believe that
³hardly any² is a lazy mental shortcut for ³Well, I don¹t like them, and I
I
don¹t use them, so I don¹t think that any anyone who¹s important uses
them.².

Yes, there are many cases in which I believe that Swift
provides looping structures that are safer and easier to understand than
the
C-style For loop. I¹d even say most cases. But I work in the scientific and
engineering domains, and can point to many instances of looping structures
that
are easily expressed with a C-style For loop, but are clumsy to implement
without it.

In the world of the natural sciences, there are any number
of instances of loop increments that requires some kind of a calculation.
There
are any number of instances of dynamically calculated loop termination.

Swift¹s stride has some nice features for simple increments,
but also has some important limitations. Among them, it involves the two
step
process of first creating an enumerable set, and then iterating over it.
In the
natural sciences, it is not uncommon for complex loop increments to be
used in
loops that are executed millions of times.

Conceptually, creating an enumerable set, and then iterating over it,
reeks of the arrogance of assuming that computing resources are unlimited.
Even
though the compiler may optimize the stride into the loop structure, it
feels
like unnecessarily creating a gigantic enumerable set.

Whether we like it or not, the enduring popularity of the
C-style For loop comes from it¹s flexibility. Swift doesn¹t have a better
alternative that also provides the same flexibility. So don¹t take it
away. If
you don¹t like it (I don¹t always either), think of something that is
clearly
superior in 100% of use cases. Even then, I would argue against removing
it.

I would argue that the C-style For loop implements some
rather Swift-like concepts. The syntax provide for three closures: one
each for
(a) things to do first, (b) things to do when deciding whether to stop
iterating, and (c) things to do after each iteration. How is that contrary
to the principals of Swift?

Just like pretty much everywhere that Swift allows closures,
they can be used to write code that is difficult to understand. But the
syntax
is general and flexible enough to have survived intact for half a century.

It¹s the carrot vs. the stick. Developers prefer the carrot.
The belief that we can force developers to write better code by taking away
language features, has not historically met with success. Let me say that
again, because I think it¹s important. Developers who are given a choice
between C and a ³better² language (say Modula-2, or Swift) are unlikely to
react favourably to being told ³we¹re taking away this feature of C that
you
like, for your own good, because you¹re too stupid to use it sensibly².
Taking away well-understood expressive language elements, and replacing
them with something less expressive, is not going to win developers over.

C-style For loops haven¹t changed in half acentury, because they work.
A lot of other languages have also adopted them, because they work.

If I may, I¹d like to take the English language by way of
analogy. English contains a lot of weird, irregular language elements.
There¹s
no single way to express a concept. Instead, there are many, subtly
different
ways to express yourself.

But, for all of its weirdness, English has remained popular
for centuries, whereas more ³sensible², ³regular² languages like Esperanto
never caught on. The reasons are flexibility and expressiveness. The same
thing
applies to computer languages.

If we only look inside the world of compilers and computer
science instruction, to see if we need the flexibility of C-style For
loops, we
might mistakenly think that we don¹t. But those domains are relatively
simple
in comparison to the physical sciences. Our experience there doesn¹t always
translate to the more complex world of physical reality. So let¹s not throw
away convenient and useful language features just because we don¹t
personally
care for them.

Don¹t make Swift Yet Another Interesting Experiment in
language design that wasn¹t widely adopted, and
ended up being relegated to the dustbin of history.
It would make me sad to see the best new computer language
in ages become just another niche language. We already
have enough of those.

So, all of you folks who voted to remove these things, please don¹t hate
me!

Regards,
J. Heerema, Ph.D.

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


(Xiaodi Wu) #3

FWIW, as an anecdote, I've been working on a side project in the
natural sciences using Swift and I haven't missed the C-style for;;
loop much. It seemed a little irksome at first to refactor, but that
was about it. Looking around at other languages, I'm also not seeing
evidence that working in the natural sciences domain
disproportionately requires these loops. For instance, Python (which
has significant uptake in my corner of the natural sciences world) and
Julia (the up-and-coming technical computing language) both lack
C-style for;; syntax and the ++ and -- operators, which doesn't seem
to have dampened the enthusiasm of my colleagues for those languages.

···

On Sat, Apr 2, 2016 at 6:45 PM, John Heerema via swift-evolution <swift-evolution@swift.org> wrote:

Yes, there are many cases in which I believe that Swift
provides looping structures that are safer and easier to understand than
the
C-style For loop. I¹d even say most cases. But I work in the scientific and
engineering domains, and can point to many instances of looping structures
that
are easily expressed with a C-style For loop, but are clumsy to implement
without it.

In the world of the natural sciences, there are any number
of instances of loop increments that requires some kind of a calculation.
There
are any number of instances of dynamically calculated loop termination.

Swift¹s stride has some nice features for simple increments,
but also has some important limitations. Among them, it involves the two
step
process of first creating an enumerable set, and then iterating over it.
In the
natural sciences, it is not uncommon for complex loop increments to be
used in
loops that are executed millions of times.

Conceptually, creating an enumerable set, and then iterating over it,
reeks of the arrogance of assuming that computing resources are unlimited.
Even
though the compiler may optimize the stride into the loop structure, it
feels
like unnecessarily creating a gigantic enumerable set.

Whether we like it or not, the enduring popularity of the
C-style For loop comes from it¹s flexibility. Swift doesn¹t have a better
alternative that also provides the same flexibility. So don¹t take it
away. If
you don¹t like it (I don¹t always either), think of something that is
clearly
superior in 100% of use cases. Even then, I would argue against removing
it.


(Taras Zakharko) #4

Hi John,

there seems to be a fundamental misunderstanding on your part how collection based (for .. in..) loops operate. The enumerable sets you talk about do not need to be created upfront - they can be virtual/lazy (however you want to describe them). So yes, the Swift for … in .. loop has essentially the same semantics as the C-style for(;:wink: loop — only in Swift this semantics is abstracted behind the Generator/Iterator protocol. Abstracting the semantics of a iterating loop has important advantages in terms of maintainability, compositionally and reusability. Imagine for instance, that you are writing a loop that needs to iterate a sparse matrix. With a for(;:wink: loop, you need to include complex loop logic into your code. With a for .. in .. loop, you only need a sequence/generator abstraction for the sparse matrix to be implemented once. The loop code itself becomes very simple. Besides, some popular language that are widely used for numerical calculations (Python, R) do not have the for(;:wink: loop — for a good reason.

Besides, I am quite sure that the purpose of Swift is not to appeal to everyone. Its purpose its to make certain things better. Things like for(;:wink: an unary decrement/increment operators are quite neat, but they ultimately result in less maintainable and comprehensive code.

Best,

Taras

···

On 03 Apr 2016, at 01:45, John Heerema via swift-evolution <swift-evolution@swift.org> wrote:

Warning - long post.
I know that some folks really hate long posts, so let me apologize right
now for this being a long post. Please feel free to skip right on past it.
I posted it on a weekend, when there¹s less mailing list traffic, but that
doesn¹t make it any shorter.

Warning - revisits two approved deprecations.
If you really, really hate it when people want to revisit decisions that
have already been made, please just skip right past this post. My
apologies for not contributing to the discussion when these decisions were
originally being made!

The day that Swift was announced at the WWDC was very
exciting for me, and I immediately read the Swift book from beginning to
end.
Swift quickly became my favourite language: I felt that the Swift language
developers had created a beautiful language that combined expressiveness
with
practicality in a way that made Swift code both powerful and easy to
understand. Swift was crafted by some very smart and practical people.

To put my thoughts into perspective, I should mention that
I¹ve taught Computer Science at a senior University level for years, and
have
worked in industry for decades. As a computer scientist, I¹ve had a strong
interest in computer languages for many years. I became an Apple developer
upon
purchasing an Apple Lisa a very long time ago.

Over the past couple of years though, I¹ve seen what I think
of as a growing emphasis on strict feature orthagonality at the expense of
practicality in Swift. Perhaps this because much of the feedback on the
language has been provided by those of us who are interested in computer
languages. But for whatever reasons, the Swift language seems to have
become
more cluttered and less friendly.

As I¹ve gone through the various beta releases, I¹ve seen
changes that detract from the experience of using Swift, for reasons that
seem
related to ³language purity².

I was finally moved to try to express my thoughts after
seeing a couple of what I think of as particularly inadvisable proposals
for
Swift version 3 and beyond.

Unary increment and decrement operators: ++ and ‹

The first of these was the now approved removal of Swift¹s
convenient unary increment and decrement operators. I would agree with
some of
the comments that have been made about these operators not being quite
orthogonal with other expressive elements in the language. Nonetheless,
they
are a handy and popular way to iterate over enumerable collections, and to
increment and decrement a variable that is used for purposes other than
iteration. They also lend themselves to being extended to other data
types, such
as position pointers in linked lists, where they can implement the
convenient
concept of ³the next thing² (which += does not provide).

The desire to get rid of these rather harmless operators
reminds me of some of Apple¹s own history, and the history of computer
languages in general. Niklaus Wirth didn¹t care for shortcut operators
either,
and so Pascal never got them.

However, Apple eventually moved away from Pascal to C, even
though C is in many ways a deeply flawed language that is responsible for a
wide litany of software errors. Why? I personally really liked Pascal, but
many
(most) developers didn¹t care for the language. I¹d argue that developers
preferred the flexibility of C to what they saw as the overly restricting
constraints of Pascal.

One of the surprising reasons that I heard a lot at the
time, was that developers didn¹t want to lose C¹s shortcut operators. If
Wirth
had been willing to give Pascal some of C¹s convenience operators, things
might
well have turned out differently. Developers hate typing.

The notion that there should be exactly one way to do a
particular thing sounds like dogma to me: not practicality. If people are
concerned that unary operators confuse beginners, I would encourage them to
convince educators not to teach them to beginners. Anyway, there are a lot
of
things in Swift that can confuse beginners!

Although it¹s hard for me to believe that having these
operators return void has been seriously considered, I would argue that
this
would be even sillier than removing them. A lot of developers use both C
(or
Objective C, C++, C#, Java, etc. etc.) and Swift ­ having those unary
operators
act completely differently in Swift would be a great way to alienate those
developers.

Let¹s not forget that Swift
is not the lingua franca of the computing world. It¹s an upstart that
needs to
attract the development community. Why repel people coming from the various
C-like languages without a really, really, convincingly good reason? it¹s
better for an upstart to attract than to repel.

Right now, there are an awful lot of developers who are used
to, and like the convenience of unary increment and decrement operators.
Removing them seems bound to annoy developers and diminish the popularity
of
Swift, in exchange for Š well, not very much except for a tiny bit of
language
purity. That just seems silly to me.

C-style For loops

Removal of C-style For loops has already been approved for a
future version of Swift. Even though I find the C-style For loop to be a
bit
ugly and unintuitive, I believe that removing it was the wrong thing to do.

It comes down to flexibility and expressiveness. The reality
is that C-style For loops easily implement certain operations that are more
difficult to implement without them.

I¹ve seen comments that C-style For loops are ³hardly ever
used², and that ³hardly any² algorithms really need them. I believe that
³hardly any² is a lazy mental shortcut for ³Well, I don¹t like them, and I
I
don¹t use them, so I don¹t think that any anyone who¹s important uses
them.².

Yes, there are many cases in which I believe that Swift
provides looping structures that are safer and easier to understand than
the
C-style For loop. I¹d even say most cases. But I work in the scientific and
engineering domains, and can point to many instances of looping structures
that
are easily expressed with a C-style For loop, but are clumsy to implement
without it.

In the world of the natural sciences, there are any number
of instances of loop increments that requires some kind of a calculation.
There
are any number of instances of dynamically calculated loop termination.

Swift¹s stride has some nice features for simple increments,
but also has some important limitations. Among them, it involves the two
step
process of first creating an enumerable set, and then iterating over it.
In the
natural sciences, it is not uncommon for complex loop increments to be
used in
loops that are executed millions of times.

Conceptually, creating an enumerable set, and then iterating over it,
reeks of the arrogance of assuming that computing resources are unlimited.
Even
though the compiler may optimize the stride into the loop structure, it
feels
like unnecessarily creating a gigantic enumerable set.

Whether we like it or not, the enduring popularity of the
C-style For loop comes from it¹s flexibility. Swift doesn¹t have a better
alternative that also provides the same flexibility. So don¹t take it
away. If
you don¹t like it (I don¹t always either), think of something that is
clearly
superior in 100% of use cases. Even then, I would argue against removing
it.

I would argue that the C-style For loop implements some
rather Swift-like concepts. The syntax provide for three closures: one
each for
(a) things to do first, (b) things to do when deciding whether to stop
iterating, and (c) things to do after each iteration. How is that contrary
to the principals of Swift?

Just like pretty much everywhere that Swift allows closures,
they can be used to write code that is difficult to understand. But the
syntax
is general and flexible enough to have survived intact for half a century.

It¹s the carrot vs. the stick. Developers prefer the carrot.
The belief that we can force developers to write better code by taking away
language features, has not historically met with success. Let me say that
again, because I think it¹s important. Developers who are given a choice
between C and a ³better² language (say Modula-2, or Swift) are unlikely to
react favourably to being told ³we¹re taking away this feature of C that
you
like, for your own good, because you¹re too stupid to use it sensibly².
Taking away well-understood expressive language elements, and replacing
them with something less expressive, is not going to win developers over.

C-style For loops haven¹t changed in half acentury, because they work.
A lot of other languages have also adopted them, because they work.

If I may, I¹d like to take the English language by way of
analogy. English contains a lot of weird, irregular language elements.
There¹s
no single way to express a concept. Instead, there are many, subtly
different
ways to express yourself.

But, for all of its weirdness, English has remained popular
for centuries, whereas more ³sensible², ³regular² languages like Esperanto
never caught on. The reasons are flexibility and expressiveness. The same
thing
applies to computer languages.

If we only look inside the world of compilers and computer
science instruction, to see if we need the flexibility of C-style For
loops, we
might mistakenly think that we don¹t. But those domains are relatively
simple
in comparison to the physical sciences. Our experience there doesn¹t always
translate to the more complex world of physical reality. So let¹s not throw
away convenient and useful language features just because we don¹t
personally
care for them.

Don¹t make Swift Yet Another Interesting Experiment in
language design that wasn¹t widely adopted, and
ended up being relegated to the dustbin of history.
It would make me sad to see the best new computer language
in ages become just another niche language. We already
have enough of those.

So, all of you folks who voted to remove these things, please don¹t hate
me!

Regards,
J. Heerema, Ph.D.

<default.xml><default[1].xml>_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Goffredo Marocchi) #5

It would be very interesting to see more examples dynamic loop conditions and dynamic loop increments using the Swifter for in loop with strides... without while :).

[[iOS messageWithData:ideas] broadcast]

···

On 3 Apr 2016, at 09:19, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote:

On Sat, Apr 2, 2016 at 6:45 PM, John Heerema via swift-evolution > <swift-evolution@swift.org> wrote:

Yes, there are many cases in which I believe that Swift
provides looping structures that are safer and easier to understand than
the
C-style For loop. I¹d even say most cases. But I work in the scientific and
engineering domains, and can point to many instances of looping structures
that
are easily expressed with a C-style For loop, but are clumsy to implement
without it.

In the world of the natural sciences, there are any number
of instances of loop increments that requires some kind of a calculation.
There
are any number of instances of dynamically calculated loop termination.

Swift¹s stride has some nice features for simple increments,
but also has some important limitations. Among them, it involves the two
step
process of first creating an enumerable set, and then iterating over it.
In the
natural sciences, it is not uncommon for complex loop increments to be
used in
loops that are executed millions of times.

Conceptually, creating an enumerable set, and then iterating over it,
reeks of the arrogance of assuming that computing resources are unlimited.
Even
though the compiler may optimize the stride into the loop structure, it
feels
like unnecessarily creating a gigantic enumerable set.

Whether we like it or not, the enduring popularity of the
C-style For loop comes from it¹s flexibility. Swift doesn¹t have a better
alternative that also provides the same flexibility. So don¹t take it
away. If
you don¹t like it (I don¹t always either), think of something that is
clearly
superior in 100% of use cases. Even then, I would argue against removing
it.

FWIW, as an anecdote, I've been working on a side project in the
natural sciences using Swift and I haven't missed the C-style for;;
loop much. It seemed a little irksome at first to refactor, but that
was about it. Looking around at other languages, I'm also not seeing
evidence that working in the natural sciences domain
disproportionately requires these loops. For instance, Python (which
has significant uptake in my corner of the natural sciences world) and
Julia (the up-and-coming technical computing language) both lack
C-style for;; syntax and the ++ and -- operators, which doesn't seem
to have dampened the enthusiasm of my colleagues for those languages.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Andrew Bennett) #6

On that note here is a convenient pattern I've used in the rare cases I
haven't been able to convert to a "for in" syntax when refactoring:

var i = 0

while i < 10 {

    defer { i += 1 }

    print(i)

}

To be honest I don't really mind this syntax, I often found during
refactoring:
* the c-style "for" was broken up over multiple lines anyway
* I wanted the last value of `i` outside the loop, so it was written "for ;
check; incr"
* It still works with continue, although it does increment "i" on break

···

On Sun, Apr 3, 2016 at 11:19 AM, Ross O'Brien via swift-evolution < swift-evolution@swift.org> wrote:

Because you're coming to the discussion late, the arguments you're making
are a little out of date. It's no longer a case of not removing these
features. It's now a case of having a compelling reason to put them back.

I trust you've read the proposals that were put forward. For the benefit
of those reading, they're here:

https://github.com/apple/swift-evolution/blob/master/proposals/0004-remove-pre-post-inc-decrement.md

https://github.com/apple/swift-evolution/blob/master/proposals/0007-remove-c-style-for-loops.md

There are several disadvantages listed for keeping these two features.
Those are the arguments you need to counter. As it happens, both proposals
refer to the metric of 'if this wasn't already in Swift, would it be
accepted for Swift 3?' and both features have been deemed to fail this
criterion. That's what you need to address.

Bear in mind these decisions were made several months ago, and both
features have already been deprecated as of Swift 2.2, which is now in use
in production code, many developers (including myself) are already
refactoring their code to remove uses of these syntax forms.

On Sun, Apr 3, 2016 at 12:45 AM, John Heerema via swift-evolution < > swift-evolution@swift.org> wrote:

Warning - long post.
I know that some folks really hate long posts, so let me apologize right
now for this being a long post. Please feel free to skip right on past it.
I posted it on a weekend, when there¹s less mailing list traffic, but that
doesn¹t make it any shorter.

Warning - revisits two approved deprecations.
If you really, really hate it when people want to revisit decisions that
have already been made, please just skip right past this post. My
apologies for not contributing to the discussion when these decisions were
originally being made!

The day that Swift was announced at the WWDC was very
exciting for me, and I immediately read the Swift book from beginning to
end.
Swift quickly became my favourite language: I felt that the Swift language
developers had created a beautiful language that combined expressiveness
with
practicality in a way that made Swift code both powerful and easy to
understand. Swift was crafted by some very smart and practical people.

To put my thoughts into perspective, I should mention that
I¹ve taught Computer Science at a senior University level for years, and
have
worked in industry for decades. As a computer scientist, I¹ve had a strong
interest in computer languages for many years. I became an Apple developer
upon
purchasing an Apple Lisa a very long time ago.

Over the past couple of years though, I¹ve seen what I think
of as a growing emphasis on strict feature orthagonality at the expense of
practicality in Swift. Perhaps this because much of the feedback on the
language has been provided by those of us who are interested in computer
languages. But for whatever reasons, the Swift language seems to have
become
more cluttered and less friendly.

As I¹ve gone through the various beta releases, I¹ve seen
changes that detract from the experience of using Swift, for reasons that
seem
related to ³language purity².

I was finally moved to try to express my thoughts after
seeing a couple of what I think of as particularly inadvisable proposals
for
Swift version 3 and beyond.

Unary increment and decrement operators: ++ and ‹

The first of these was the now approved removal of Swift¹s
convenient unary increment and decrement operators. I would agree with
some of
the comments that have been made about these operators not being quite
orthogonal with other expressive elements in the language. Nonetheless,
they
are a handy and popular way to iterate over enumerable collections, and to
increment and decrement a variable that is used for purposes other than
iteration. They also lend themselves to being extended to other data
types, such
as position pointers in linked lists, where they can implement the
convenient
concept of ³the next thing² (which += does not provide).

The desire to get rid of these rather harmless operators
reminds me of some of Apple¹s own history, and the history of computer
languages in general. Niklaus Wirth didn¹t care for shortcut operators
either,
and so Pascal never got them.

However, Apple eventually moved away from Pascal to C, even
though C is in many ways a deeply flawed language that is responsible for
a
wide litany of software errors. Why? I personally really liked Pascal, but
many
(most) developers didn¹t care for the language. I¹d argue that developers
preferred the flexibility of C to what they saw as the overly restricting
constraints of Pascal.

One of the surprising reasons that I heard a lot at the
time, was that developers didn¹t want to lose C¹s shortcut operators. If
Wirth
had been willing to give Pascal some of C¹s convenience operators, things
might
well have turned out differently. Developers hate typing.

The notion that there should be exactly one way to do a
particular thing sounds like dogma to me: not practicality. If people are
concerned that unary operators confuse beginners, I would encourage them
to
convince educators not to teach them to beginners. Anyway, there are a lot
of
things in Swift that can confuse beginners!

Although it¹s hard for me to believe that having these
operators return void has been seriously considered, I would argue that
this
would be even sillier than removing them. A lot of developers use both C
(or
Objective C, C++, C#, Java, etc. etc.) and Swift ­ having those unary
operators
act completely differently in Swift would be a great way to alienate those
developers.

Let¹s not forget that Swift
is not the lingua franca of the computing world. It¹s an upstart that
needs to
attract the development community. Why repel people coming from the
various
C-like languages without a really, really, convincingly good reason? it¹s
better for an upstart to attract than to repel.

Right now, there are an awful lot of developers who are used
to, and like the convenience of unary increment and decrement operators.
Removing them seems bound to annoy developers and diminish the popularity
of
Swift, in exchange for Š well, not very much except for a tiny bit of
language
purity. That just seems silly to me.

C-style For loops

Removal of C-style For loops has already been approved for a
future version of Swift. Even though I find the C-style For loop to be a
bit
ugly and unintuitive, I believe that removing it was the wrong thing to
do.

It comes down to flexibility and expressiveness. The reality
is that C-style For loops easily implement certain operations that are
more
difficult to implement without them.

I¹ve seen comments that C-style For loops are ³hardly ever
used², and that ³hardly any² algorithms really need them. I believe that
³hardly any² is a lazy mental shortcut for ³Well, I don¹t like them, and I
I
don¹t use them, so I don¹t think that any anyone who¹s important uses
them.².

Yes, there are many cases in which I believe that Swift
provides looping structures that are safer and easier to understand than
the
C-style For loop. I¹d even say most cases. But I work in the scientific
and
engineering domains, and can point to many instances of looping structures
that
are easily expressed with a C-style For loop, but are clumsy to implement
without it.

In the world of the natural sciences, there are any number
of instances of loop increments that requires some kind of a calculation.
There
are any number of instances of dynamically calculated loop termination.

Swift¹s stride has some nice features for simple increments,
but also has some important limitations. Among them, it involves the two
step
process of first creating an enumerable set, and then iterating over it.
In the
natural sciences, it is not uncommon for complex loop increments to be
used in
loops that are executed millions of times.

Conceptually, creating an enumerable set, and then iterating over it,
reeks of the arrogance of assuming that computing resources are unlimited.
Even
though the compiler may optimize the stride into the loop structure, it
feels
like unnecessarily creating a gigantic enumerable set.

Whether we like it or not, the enduring popularity of the
C-style For loop comes from it¹s flexibility. Swift doesn¹t have a better
alternative that also provides the same flexibility. So don¹t take it
away. If
you don¹t like it (I don¹t always either), think of something that is
clearly
superior in 100% of use cases. Even then, I would argue against removing
it.

I would argue that the C-style For loop implements some
rather Swift-like concepts. The syntax provide for three closures: one
each for
(a) things to do first, (b) things to do when deciding whether to stop
iterating, and (c) things to do after each iteration. How is that
contrary
to the principals of Swift?

Just like pretty much everywhere that Swift allows closures,
they can be used to write code that is difficult to understand. But the
syntax
is general and flexible enough to have survived intact for half a century.

It¹s the carrot vs. the stick. Developers prefer the carrot.
The belief that we can force developers to write better code by taking
away
language features, has not historically met with success. Let me say that
again, because I think it¹s important. Developers who are given a choice
between C and a ³better² language (say Modula-2, or Swift) are unlikely to
react favourably to being told ³we¹re taking away this feature of C that
you
like, for your own good, because you¹re too stupid to use it sensibly².
Taking away well-understood expressive language elements, and replacing
them with something less expressive, is not going to win developers over.

C-style For loops haven¹t changed in half acentury, because they work.
A lot of other languages have also adopted them, because they work.

If I may, I¹d like to take the English language by way of
analogy. English contains a lot of weird, irregular language elements.
There¹s
no single way to express a concept. Instead, there are many, subtly
different
ways to express yourself.

But, for all of its weirdness, English has remained popular
for centuries, whereas more ³sensible², ³regular² languages like Esperanto
never caught on. The reasons are flexibility and expressiveness. The same
thing
applies to computer languages.

If we only look inside the world of compilers and computer
science instruction, to see if we need the flexibility of C-style For
loops, we
might mistakenly think that we don¹t. But those domains are relatively
simple
in comparison to the physical sciences. Our experience there doesn¹t
always
translate to the more complex world of physical reality. So let¹s not
throw
away convenient and useful language features just because we don¹t
personally
care for them.

Don¹t make Swift Yet Another Interesting Experiment in
language design that wasn¹t widely adopted, and
ended up being relegated to the dustbin of history.
It would make me sad to see the best new computer language
in ages become just another niche language. We already
have enough of those.

So, all of you folks who voted to remove these things, please don¹t hate
me!

Regards,
J. Heerema, Ph.D.

_______________________________________________
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


(Charles Srstka) #7

While this style works, and definitely can substitute for a classical for loop, it is not quite as nice, because it cannot limit i’s scope to the loop. The variable will be visible outside of the loop body.

Charles

···

On Apr 2, 2016, at 8:43 PM, Andrew Bennett via swift-evolution <swift-evolution@swift.org> wrote:

On that note here is a convenient pattern I've used in the rare cases I haven't been able to convert to a "for in" syntax when refactoring:

var i = 0
while i < 10 {
    defer { i += 1 }
    print(i)
}

To be honest I don't really mind this syntax, I often found during refactoring:
* the c-style "for" was broken up over multiple lines anyway
* I wanted the last value of `i` outside the loop, so it was written "for ; check; incr"
* It still works with continue, although it does increment "i" on break

On Sun, Apr 3, 2016 at 11:19 AM, Ross O'Brien via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Because you're coming to the discussion late, the arguments you're making are a little out of date. It's no longer a case of not removing these features. It's now a case of having a compelling reason to put them back.

I trust you've read the proposals that were put forward. For the benefit of those reading, they're here:
https://github.com/apple/swift-evolution/blob/master/proposals/0004-remove-pre-post-inc-decrement.md
https://github.com/apple/swift-evolution/blob/master/proposals/0007-remove-c-style-for-loops.md

There are several disadvantages listed for keeping these two features. Those are the arguments you need to counter. As it happens, both proposals refer to the metric of 'if this wasn't already in Swift, would it be accepted for Swift 3?' and both features have been deemed to fail this criterion. That's what you need to address.

Bear in mind these decisions were made several months ago, and both features have already been deprecated as of Swift 2.2, which is now in use in production code, many developers (including myself) are already refactoring their code to remove uses of these syntax forms.

On Sun, Apr 3, 2016 at 12:45 AM, John Heerema via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Warning - long post.
I know that some folks really hate long posts, so let me apologize right
now for this being a long post. Please feel free to skip right on past it.
I posted it on a weekend, when there¹s less mailing list traffic, but that
doesn¹t make it any shorter.

Warning - revisits two approved deprecations.
If you really, really hate it when people want to revisit decisions that
have already been made, please just skip right past this post. My
apologies for not contributing to the discussion when these decisions were
originally being made!

The day that Swift was announced at the WWDC was very
exciting for me, and I immediately read the Swift book from beginning to
end.
Swift quickly became my favourite language: I felt that the Swift language
developers had created a beautiful language that combined expressiveness
with
practicality in a way that made Swift code both powerful and easy to
understand. Swift was crafted by some very smart and practical people.

To put my thoughts into perspective, I should mention that
I¹ve taught Computer Science at a senior University level for years, and
have
worked in industry for decades. As a computer scientist, I¹ve had a strong
interest in computer languages for many years. I became an Apple developer
upon
purchasing an Apple Lisa a very long time ago.

Over the past couple of years though, I¹ve seen what I think
of as a growing emphasis on strict feature orthagonality at the expense of
practicality in Swift. Perhaps this because much of the feedback on the
language has been provided by those of us who are interested in computer
languages. But for whatever reasons, the Swift language seems to have
become
more cluttered and less friendly.

As I¹ve gone through the various beta releases, I¹ve seen
changes that detract from the experience of using Swift, for reasons that
seem
related to ³language purity².

I was finally moved to try to express my thoughts after
seeing a couple of what I think of as particularly inadvisable proposals
for
Swift version 3 and beyond.

Unary increment and decrement operators: ++ and ‹

The first of these was the now approved removal of Swift¹s
convenient unary increment and decrement operators. I would agree with
some of
the comments that have been made about these operators not being quite
orthogonal with other expressive elements in the language. Nonetheless,
they
are a handy and popular way to iterate over enumerable collections, and to
increment and decrement a variable that is used for purposes other than
iteration. They also lend themselves to being extended to other data
types, such
as position pointers in linked lists, where they can implement the
convenient
concept of ³the next thing² (which += does not provide).

The desire to get rid of these rather harmless operators
reminds me of some of Apple¹s own history, and the history of computer
languages in general. Niklaus Wirth didn¹t care for shortcut operators
either,
and so Pascal never got them.

However, Apple eventually moved away from Pascal to C, even
though C is in many ways a deeply flawed language that is responsible for a
wide litany of software errors. Why? I personally really liked Pascal, but
many
(most) developers didn¹t care for the language. I¹d argue that developers
preferred the flexibility of C to what they saw as the overly restricting
constraints of Pascal.

One of the surprising reasons that I heard a lot at the
time, was that developers didn¹t want to lose C¹s shortcut operators. If
Wirth
had been willing to give Pascal some of C¹s convenience operators, things
might
well have turned out differently. Developers hate typing.

The notion that there should be exactly one way to do a
particular thing sounds like dogma to me: not practicality. If people are
concerned that unary operators confuse beginners, I would encourage them to
convince educators not to teach them to beginners. Anyway, there are a lot
of
things in Swift that can confuse beginners!

Although it¹s hard for me to believe that having these
operators return void has been seriously considered, I would argue that
this
would be even sillier than removing them. A lot of developers use both C
(or
Objective C, C++, C#, Java, etc. etc.) and Swift ­ having those unary
operators
act completely differently in Swift would be a great way to alienate those
developers.

Let¹s not forget that Swift
is not the lingua franca of the computing world. It¹s an upstart that
needs to
attract the development community. Why repel people coming from the various
C-like languages without a really, really, convincingly good reason? it¹s
better for an upstart to attract than to repel.

Right now, there are an awful lot of developers who are used
to, and like the convenience of unary increment and decrement operators.
Removing them seems bound to annoy developers and diminish the popularity
of
Swift, in exchange for Š well, not very much except for a tiny bit of
language
purity. That just seems silly to me.

C-style For loops

Removal of C-style For loops has already been approved for a
future version of Swift. Even though I find the C-style For loop to be a
bit
ugly and unintuitive, I believe that removing it was the wrong thing to do.

It comes down to flexibility and expressiveness. The reality
is that C-style For loops easily implement certain operations that are more
difficult to implement without them.

I¹ve seen comments that C-style For loops are ³hardly ever
used², and that ³hardly any² algorithms really need them. I believe that
³hardly any² is a lazy mental shortcut for ³Well, I don¹t like them, and I
I
don¹t use them, so I don¹t think that any anyone who¹s important uses
them.².

Yes, there are many cases in which I believe that Swift
provides looping structures that are safer and easier to understand than
the
C-style For loop. I¹d even say most cases. But I work in the scientific and
engineering domains, and can point to many instances of looping structures
that
are easily expressed with a C-style For loop, but are clumsy to implement
without it.

In the world of the natural sciences, there are any number
of instances of loop increments that requires some kind of a calculation.
There
are any number of instances of dynamically calculated loop termination.

Swift¹s stride has some nice features for simple increments,
but also has some important limitations. Among them, it involves the two
step
process of first creating an enumerable set, and then iterating over it.
In the
natural sciences, it is not uncommon for complex loop increments to be
used in
loops that are executed millions of times.

Conceptually, creating an enumerable set, and then iterating over it,
reeks of the arrogance of assuming that computing resources are unlimited.
Even
though the compiler may optimize the stride into the loop structure, it
feels
like unnecessarily creating a gigantic enumerable set.

Whether we like it or not, the enduring popularity of the
C-style For loop comes from it¹s flexibility. Swift doesn¹t have a better
alternative that also provides the same flexibility. So don¹t take it
away. If
you don¹t like it (I don¹t always either), think of something that is
clearly
superior in 100% of use cases. Even then, I would argue against removing
it.

I would argue that the C-style For loop implements some
rather Swift-like concepts. The syntax provide for three closures: one
each for
(a) things to do first, (b) things to do when deciding whether to stop
iterating, and (c) things to do after each iteration. How is that contrary
to the principals of Swift?

Just like pretty much everywhere that Swift allows closures,
they can be used to write code that is difficult to understand. But the
syntax
is general and flexible enough to have survived intact for half a century.

It¹s the carrot vs. the stick. Developers prefer the carrot.
The belief that we can force developers to write better code by taking away
language features, has not historically met with success. Let me say that
again, because I think it¹s important. Developers who are given a choice
between C and a ³better² language (say Modula-2, or Swift) are unlikely to
react favourably to being told ³we¹re taking away this feature of C that
you
like, for your own good, because you¹re too stupid to use it sensibly².
Taking away well-understood expressive language elements, and replacing
them with something less expressive, is not going to win developers over.

C-style For loops haven¹t changed in half acentury, because they work.
A lot of other languages have also adopted them, because they work.

If I may, I¹d like to take the English language by way of
analogy. English contains a lot of weird, irregular language elements.
There¹s
no single way to express a concept. Instead, there are many, subtly
different
ways to express yourself.

But, for all of its weirdness, English has remained popular
for centuries, whereas more ³sensible², ³regular² languages like Esperanto
never caught on. The reasons are flexibility and expressiveness. The same
thing
applies to computer languages.

If we only look inside the world of compilers and computer
science instruction, to see if we need the flexibility of C-style For
loops, we
might mistakenly think that we don¹t. But those domains are relatively
simple
in comparison to the physical sciences. Our experience there doesn¹t always
translate to the more complex world of physical reality. So let¹s not throw
away convenient and useful language features just because we don¹t
personally
care for them.

Don¹t make Swift Yet Another Interesting Experiment in
language design that wasn¹t widely adopted, and
ended up being relegated to the dustbin of history.
It would make me sad to see the best new computer language
in ages become just another niche language. We already
have enough of those.

So, all of you folks who voted to remove these things, please don¹t hate
me!

Regards,
J. Heerema, Ph.D.

_______________________________________________
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

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


(David Sweeris) #8

I agree it's not as nice aesthetically, but does the loop variable being visible outside the loop cause any real-world problems?

- Dave Sweeris

···

On Apr 2, 2016, at 20:49, Charles Srstka via swift-evolution <swift-evolution@swift.org> wrote:

While this style works, and definitely can substitute for a classical for loop, it is not quite as nice, because it cannot limit i’s scope to the loop. The variable will be visible outside of the loop body.


(David Owens II) #9

The C99 spec changed the scoping rules to address the very issue you are asking about having any "real-world impact".

Yes, the variable outside does matter. It's why you see some code like this, even with C++ because it used to not scope locally there too with all compilers:

{for (int i= 0; i<10; i++) { ... }}

And as fully explained in the previous threads on the topic, the defer pattern is an insufficient mechanism to generically be used for all c-style for loop constructs.

-David

···

Sent from my iPad

On Apr 2, 2016, at 7:35 PM, David Sweeris via swift-evolution <swift-evolution@swift.org> wrote:

On Apr 2, 2016, at 20:49, Charles Srstka via swift-evolution <swift-evolution@swift.org> wrote:

While this style works, and definitely can substitute for a classical for loop, it is not quite as nice, because it cannot limit i’s scope to the loop. The variable will be visible outside of the loop body.

I agree it's not as nice aesthetically, but does the loop variable being visible outside the loop cause any real-world problems?

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


#10

Interesting pattern, it closely match with the "sugar" that C provides around ‘while’ in the form of 'for(;;)’

The following C snippet

#define INITIALIZER (i = 0)
#define TEST (i < 10)
#define STEPPER (i += 1)

for (INITIALIZER; TEST; STEPPER)
{
  if (i % 2 == 0) { continue; }
  if (i % 5 == 0) { break; }
  printf("%d\n",i);
}

can be written (reusing the #define)

INITIALIZER;
while TEST
{
  if (i % 2 == 0) { STEPPER; continue; }
  if (i % 5 == 0) { break; }
  printf("%d\n",i);
  STEPPER;
}

Beside the break issue, making use of ‘defer’ causes the nested continue to misbehave:

    var i = 0
    loop_i:
    while i < 10 {
        defer { i += 1 }
        defer { print("---",j) }
        var j = 0
        loop_j:
        while j < 10 {
            defer { j += 1 }
            if j % 2 == 0 { continue loop_j }
            if j % 5 == 0 { continue loop_i }
            print(i,j)
        }
    }

In this example, the ‘continue loop_i’ does increase ‘j’, but I would not expect that; since C doesn't allow to directly continue an outer loop I cannot compare my opinion against the real world.

Should we pursue having a ‘defer(@oncontinue)’ or a new ‘continuer’ (don’t really like that name)?

With this lone new syntax, all the imaginable 'for(;;)’ can be blindly ported to Swift, with all the advantages and disadvantages of the C version. Reusing my #define as placeholders, any C-world ‘for(;;)’ can be written in Swift as:

  INITIALIZER
  while TEST
  {
    defer(@oncontinue) { STEPPER }
    // Work load
  }

In a nested loop environment, this could be used like:

    var i = 0
    loop_i:
    while i < 10 {
        defer(@onncontinue) { i += 1 }
        var j = 0
        loop_j:
        while j < 10 {
            defer(@oncontinue) { j += 1 }
            if j % 2 == 0 { continue loop_j /* j += 1 */}
            if j % 5 == 0 { continue loop_i /* i += 1, but NOT j += 1*/}
            print(i,j)
            // continue loop_j // implicit, so j += 1
        }
        // continue loop_i // implicit, so i += 1
    }

Dany

···

Le 2 avr. 2016 à 21:43, Andrew Bennett via swift-evolution <swift-evolution@swift.org> a écrit :

On that note here is a convenient pattern I've used in the rare cases I haven't been able to convert to a "for in" syntax when refactoring:

var i = 0
while i < 10 {
    defer { i += 1 }
    print(i)
}

To be honest I don't really mind this syntax, I often found during refactoring:
* the c-style "for" was broken up over multiple lines anyway
* I wanted the last value of `i` outside the loop, so it was written "for ; check; incr"
* It still works with continue, although it does increment "i" on break