The Swift Programming Language's Most Commonly Rejected Changes (github.com)

An anonymous reader writes: When Apple made its Swift programming language open source in early December, it opened the floodgates for suggestions and requests from developers. But the project's maintainers have their own ideas about how the language should evolve, so some suggestions are rejected. Now a list has been compiled of some commonly rejected proposals — it's an interesting window into the development of a language. Swift's developers don't want to replace Brace Syntax with Python-style indentation. They don't want to change boolean operators from && and || to 'and' and 'or'. They don't want to rewrite the Swift compiler in Swift. They don't want to change certain keywords like 'continue' from their C precedents. And they have no interest in removing semicolons.

Comments

Eminently Practical

[SuperKendall]

The list and the explanations of why things were rejected really does a great job of illustrating why I like Swift - because the people behind the design have a great amount of practicality tempering the desire to include every modern language feature. It makes Swift nicer to work in, and in the long run will make it a LOT nicer to maintain.

Re:Duh

[JustBoo]

Don't like it? Fork it!

Or don't use it. It is not as if we were short of programming languages.

Perhaps you guys are not aware that Swift is a language to program Apple DuH-vices. iPhones, iPads etcetera. There are NOT a lot of choices of languages when it comes to that.

But I am glad Apple is not buying the Script Kiddies Crap and 'dumbing' down the language. Python is the last language on Earth anyone should be modeling a professional language on. The Last.

Channels that apply line.strip() for line in msg

[tepples]

Also, in Python you indent the same way you should be doing anyway, just without the braces. Unless, of course, you're also doing indentation wrong.

Several channels through which people discuss program code strip leading and trailing whitespace on each line. This transforms all programs passed through them into programs that are "doing indentation wrong." Yes, in theory, these channels are defective. Yet people work around these defects using tools such as GNU indent because a defective channel gets work done better than no channel at all.

Re: People actually *like* Python whitespace?

[TheRaven64]

I'd object to it a lot less if it would either do the sensible thing and treat one tabulator as one indent level and erroring at parse time if a line contained any spaces before the first non-space character, or the slightly less sensible thing of treating n spaces as one indent level and erroring if the line contained any tabs before the first non-whitespace character. Allowing tabs and spaces to be mixed at the start of a line so that your code may look correct but is interpreted differently is annoying and is one of the many reasons why the only times I've ever written Python have been when I've fixed someone else's 'working' and shipped code. It's even worse than the semantics of else clauses on for loops for introducing subtle bugs.

Re:They're called architects

[TheRaven64]

The problem with this attitude is that compilers really should be written in a language that's good for writing compilers. This leaves you two choices:

• Write your compiler in an inappropriate language.
• Make your language good for writing compilers, at the expense of its intended uses.

Re:Python

[JazzHarper]

In 1976, Stuart Feldman, the author of make(3) at Bell Labs, realized too late that using tab as a significant character (to distinguish recipes from rules) in makefiles was a Bad Idea. In an interview, he admitted, "And then a few weeks later I had a user population of about a dozen, most of them friends, and I didn’t want to screw up my embedded base. The rest, sadly, is history."

Re:People actually *like* Python whitespace?

[Anonymous Coward]

I do most work in python know, though for most of my life I used C and C++. Python and Emacs just lets me complete some quick and dirty tasks.

If I had to do actual work in Python, it would be annoying. There have been many times when the indention protocol created errors that were difficult to fix. The brackets in C, the operators, make a lot of sense for professional code.

Re: People actually *like* Python whitespace?

[Anonymous Coward]

It has happened when you use --ignore-whitespaces when merging with git.
Most of the code in the repository isn't Python and the Python code was part of something that wasn't run often, so we didn't notice the bad indentation from ignoreing the whitespace during the merge.

Re: People actually *like* Python whitespace?

[faffod]

[...] There's a perennial C logic bug where you take an if statement with a one-line body and add a second line without adding braces to denote a block; that never happens in Python.

This is why Swift explicitly does not allow for one line statements without curly braces.

more generally speaking, the language tries to avoid things that lead to dumb mistakes, no default fall through on switch case statements, explicitly requiring every case in a switch to be accounted for, etc. Anytime you imply meaning you introduce the potential for had to find bugs - especially later in the code development cycle when someone adds seemingly innocent changes.

Re: People actually *like* Python whitespace?

[TheGratefulNet]

also, 100% this.

I could care less what human-A did for his indenting, at least on C code. if the code works and compiles, I can FIX his indentation and not ruin a thing; only make it more readable.

there is no concept of a re-indent or auto-indent (such as found in emacs, for example) for python. you can't do it. because as I posted before about this: there are 2 things and they should never be mixed. one is a cue to the compiler what a block is, and the other is a cue to the HUMAN what a block is. and combining them is what guido fucked up, on.

in C, I can do whatever wild indenting I want and a re-indent can fix it so I can read it again. I got very used to that. code was ROBUST in this way, and humans can mess with the look of it without doing harm. if I move a block from some inline code to a nested routine, it always ALWAYS works. not so in python. in fact, I'm not even sure HOW to move a block from one level of indent to another with perfect safety. its just STUPID!!!! stupid beyond belief to those of us who have been writing code for decades (I'm mid 50's and have been doing software eng work since my teens).

part of me wants to add a feature to the language so I can add braces back again, then preproc the source to remove it as a phase before running the code. I know it won't be accepted by anyone in my company but it would restore sanity to my own python projects, at least.

imagine a source code control system where check-out gets you those braces, you do your edits and each time you save the file to local git or svn (etc) it removes the bad chars and makes it 'real python' again so you can run it. that way you kind of have it both ways and editing, at least, is now more safe.