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

People actually *like* Python whitespace?

[Anonymous Coward]

Swift's developers don't want to replace Brace Syntax with Python-style indentation.

I am appalled that enough people like the idea of significant whitespace in Python to actually ask for it as a feature.

Re:People actually *like* Python whitespace?

[mveloso]

Yeah, it's crazy. "Let's make some invisible character with a variable width significant."

Re: People actually *like* Python whitespace?

[Anonymous Coward]

because when i'm moving blocks around, whitespace changes turn my original program into a
perfectly valid other program which has nothing to do with my original intent ..umm.wait...

Re: People actually *like* Python whitespace?

[Anonymous Coward]

You're right, designing a language the fucks up based on different text editor default preferences makes the users that are complaining about that design decision wrong ...

Please explain the advantage of white space sensitivity without sounding like a moron, go:

The advantage of white space sensitivity is that it reduces the visual noise when producing and reading source code, and it helps build in a consistent look and feel for the language. For instance with F#, the designers are using white space sensitivity to remove a large amount of boiler plate syntax, which makes for a much more concise language. Conciseness is very important because you can fit complex data manipulations into small blocks of very readable code, which is the core of the design team's tenant of "Do more with less code".

If you want to avoid, indentation errors you use the begin ... end blocks, but for most functions and types they are quite unnecessary. If you want to compress multiple assignments on a single line, use the let ... in ... syntax. F# also makes \t illegal when white space sensitive code is in use. With proper language design, white space sensitivity is a productivity advantage, and it does not sacrifice program readability.

Does this mean that white space sensitivity is outright superior to visual token semantic block delimiters? No of course not, it does mean that there is a trade-off space for the feature within the language's design so some languages are designed better than others.

There is also a trade-off space for using text editors instead of IDEs for programming. Sure you can stick to your favorite text editor, but you lose a large amount of useful information and features that IDEs that understand your programming language will give you, and since text editors are text editors and not program editors, they are completely correct when they display whitespace in semantically incorrect representations of the programming language.

Some whitespace sensitive languages like Python have warts when you use a language unaware text editor because Python's design considerations did not standardize and enforce in the interpreter how to use whitespace from different text editors. However, if you are using a text editor for programming, you are in a sense "doing it wrong" for many programming languages. Maybe you are fine with your current language, but if you are going to try a different language you should use the appropriate tools for that language. Use the right tools for the job. You wouldn't try to cut a 2 by 4 plank with a jeweler's saw would you? If not, do not use a text editor that is Python agnostic to edit Python code. It is really that simple. If you are collaboratively creating Python programs with others, adopt PEP-8.

Re: People actually *like* Python whitespace?

[TheGratefulNet]

100% this!

twice in the first few months of my learning python, I saw someone post code on a web forum that was impossible to know what the intent was; because the spacing was messed up (web forums do this all the time) and this, alone, proved to me how stupid this braceless style of space-sensitive indenting was.

there are 2 things and they should NOT be combined! one is for the compiler to define what a block is. the other is documentation for humans, so we know what the block is.

and yes, they do act differently. I can use white space to tell a HUMAN things but white space is quite a stupid way to talk to a computer.

there's a lot I like about python, but guido is just plain wrong, here, and its frustrating that he won't admit it.

They're called architects

[BitZtream]

The people who have their own ideas about how it should evolved are called architects, and they have their own opinion so that the language has some sort of coherency and isn't a complete and utter mess, which is what results when you do design committee.

Nice inflammatory summary though, no bias.

Swift's developers don't want to replace Brace Syntax with Python-style indentation.

No shit, they aren't retarded. Have you people not learned how stupid that is yet, how many retarded bugs do you have to have from the wrong spacing before you get it through your heads that it was a stupid fucking idea?

They don't want to change boolean operators from && and || to 'and' and 'or'.

No shit, they aren't idiots.

They don't want to rewrite the Swift compiler in Swift.

No shit, they aren't retarded. Other than proving something, WHY WOULD YOU? NO ONE DOES THIS unless they are just trying to swing their dick around. You write your languages in C with ASM for the places it makes sense. Unless you just like to make yourself need two compilers, one to compile your language so you can build your compiler in your language. Again, retarded.

They don't want to change certain keywords like 'continue' from their C precedents.

No shit, they aren't idiots.

And they have no interest in removing semicolons.

No shit, they aren't idiots.

If you had half a clue, or simply had read the second sentence under most of those things I wouldn't be the one pointing out that you're not qualified to be talking about language enhancements. Hell, as stated, almost all of these things are changes for someones personal pet preference, not because its useful for anything.

Swift IS INTENTIONALLY C like, intentionally. ALL of those requests are utterly stupid when your talking about a language that is intentionally like C/C++. If you want python ... USE PYTHON.

Re:They're called architects

[Kohath]

As a python programmer for 15 years, I've never had a bug caused by indentation changing the logic.

"It's never been a problem for me" is not an argument in favor of anyone using it except you.

"My plan/software/language has a zillion failure modes and hidden quirks, but I have them all memorized and they don't cause me problems. Let's roll this out to the general public."

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.

Re:Rust has made Swift obsolete already.

[Anubis IV]

[Rust] is the successor to Swift, and is an improvement in every way.

By definition, how can Rust be a successor to Swift, when Swift wasn't even announced until 2 years after Rust's first release?

I don't have a horse in this race, but statements like that one I quoted make it fairly evident that your comments carry a heavy slant. Moreover, given the pedigree of both Rust and Swift, it seems like a pretty bold claim to suggest that either one could be "an improvement in every way" over the other. That's made even more true by the fact that both are in active development with lots of changes happening and that both of them are borrowing the best ideas from the other.

Choose the language that suits your task and platform best, whether that's Rust, Swift, Go, C++, Python, ASM, or something else entirely. Don't lock yourself down to one view for how all programming is supposed to work, since that's a quick path to obsolescence.

Wrong, I don't

[SuperKendall]

Indentation is how you communicate block structure to a human reader. You're going to indent your code anyway

No, I am not. That's why I have a computer, to do tedious things for me - like correctly indenting code... pretty much every function I write I can write loosely and then simply tell the editor to re-indent my code correctly.

And that is why Python and Fortran are really the only languages I dislike, because they are the only ones (that I have used anyway) where the code CANNOT BE FORMATTED, because you have to know what code does in order to format it. In Fortran a character being present at a certain indent level meant that line was really a comment - oops!

But in Python you are far worse off, because the wrong indent changes execution, changes what you meant the program to do. There's no way for a formatter to guess how the code SHOULD be structured, so it cannot be - ensuring a life of tedium and very probable mistakes for coders that follow after the first one.

Python is the Wolverine of coding languages, the ultimate loner language.