
Swift: Commonly Rejected Changes - ingve
https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md
======
BinaryIdiot
This is a good reference to many existing discussions. While I will likely not
have time to contribute to Swift it's cool to be able to look at these and see
why things are the way they are.

> Replace {} Brace Syntax with Python-style indentation: Surely a polarizing
> issue, but Swift will not change to use indentation for scoping instead of
> curly braces..

I'm happy this won't happen. As much as I like Python the scoping based on
spaces messes me up far too frequently and I yearn to be able to use braces to
define my blocks. No idea if I'm in the minority or majority here but I like
the explicitness of my braces :)

~~~
_ak
There's a good reason to keep the {} syntax beyond polarization: it enables
you to programatically change/fix indentation, because the supposed levels can
be recognized by the level of {}. That's something you can't so in a
Pythonesquely structured code.

~~~
cwzwarich
Why does it make sense to have this particular syntactic redundancy and not
one of the many others that has been proposed? You could make a similar
argument that Algol-style 'if' / 'fi' pairs help eliminate brace errors where
you accidentally close the wrong construct, but clearly they have not been
popular in recent years.

~~~
nly
Syntax highlighting and code folding in editors/IDEs kind of killed the
argument for if/fi or Pascalesque begin/end... even in C++, to terminate
heavily parened expressions, I can just thrash ) until my editor tells me I'm
done, then run it through clang-format to clean it up.

~~~
alricb
One advantage of not using {} for blocks is that they are available for other
purposes, like generics or templates, instead of the terrible <>, combinations
like (::) or unicode characters.

~~~
kuschku
Why are <> so terrible? I mean, they’re more accessible than {}.

<> is next to shift on the keyboard, {} is AltGr+7/9.

~~~
masklinn
> Why are <> so terrible? I mean, they’re more accessible than {}.

The problem is parsing complexity, they have to be disambiguated from the
corresponding operators (also the right shift `>>`), so either the syntax has
to be such that they can't appear in the same context and can be trivially
differentiated, or you got yourself an exponentially harder to parse language.

~~~
fao_
That can be solved relatively simply with lookahead, can't it?

~~~
nly
Nope, because you can have arbitrary constant expressions within template
instantiations.

foo<bar<1> could be interpreted as "foo<(bar < 1)>" or "foo < bar<1>"

It's undecidable without symbol lookup.

------
masklinn
> Rewrite the Swift compiler in Swift: This would be a lot of fun someday, but
> (unless you include rewriting all of LLVM) requires the ability to import
> C++ APIs into Swift.

Or write thin bindings exposing a C API to the bits of LLVM you need to invoke
to drive the backend. I believe that's what Rust does[0], because you
definitely can't import C++ in Rust, rustc is written in Rust, and yet it uses
LLVM.

[0] might be in [https://github.com/rust-
lang/rust/tree/master/src/rustllvm](https://github.com/rust-
lang/rust/tree/master/src/rustllvm) though I'm not quite sure

~~~
cwzwarich
Swift's compiler uses a lot more functionality from LLVM than Rust's compiler.
For example, Clang's C++ API is used to parse and type-check C / Objective-C
headers. Potential interoperability with C++ in the future would make this API
surface even larger.

~~~
masklinn
C++ interop would make the whole issue moot since you wouldn't need most of
the shim anymore: you'd only have to shim enough to interop with C++, then
from that could call the LLVM API directly.

~~~
cwzwarich
That's a good point, although full C++ interoperability may be many years out,
and it would probably have to include things like templates for that plan to
work.

------
tpush
_if /else and switch as expressions: These are conceptually interesting things
to support, but many of the problems solved by making these into expressions
are already solved in Swift in other ways. Making them expressions introduces
significant tradeoffs, and on balance, we haven't found a design that is
clearly better than what we have so far._

I wonder what these significant tradeoffs are? if/else and switch not being
expressions makes certain code really awkward to write. Luckily Swift doesn't
force you to use mutability here, but it's still weird IMO.

~~~
jayrhynas
There's a few more details in the linked mailing list post[0]:

 _Exactly which statements should be included (certainly if and switch, any
others)?_

 _Further, it is important to consider whether the code written using this
will actually be_ better _than the code written with these things as
statements. For example, the “switch” blocks tend to be very large, and
turning them into expressions encourages additional indentation. Swift already
allows ‘let’ values to be initialized on multiple paths, so is the win
actually that great?_

 _Given that statements-as-expressions would provide another way to do things
(they are a purely syntax extension) the barrier should high to add them. They
will add complexity and surface area to the language, so they need to pay that
complexity._

[0] [https://lists.swift.org/pipermail/swift-
evolution/2015-Decem...](https://lists.swift.org/pipermail/swift-
evolution/2015-December/000393.html)

~~~
tpush
Well d'oh, should've clicked the link. Thanks :-)

I would argue that allowing 'let' values to be initialized on multiple paths
is uglier than having them be always initialized by exactly one expression.
But, I see their point.

------
frou_dh
It's a good point that "continue" is a wildly bad keyword for what it actually
does. It only becomes appropriate when considered as augmenting a silent
"break", i.e. "break, though continue looping".

------
jaseemabid
Reasons to reject "if/else and switch as expressions" looks very naive. Can't
believe it's coming from Chris Lattner. A lot of languages like Python,
Haskell and Rust got this right.

~~~
AlphaSite
Python doesn't do or/else as an expression, does it?

~~~
gsnedders
`"yes" if foo else "no"`

~~~
rdw
That's a ternary, not an if expression.

~~~
emn13
The difference being?

~~~
kazagistar
You can not have full blocks, only expressions.

~~~
emn13
And in an if-expression, you similarly can have expressions. Some of those
expressions might be blocks.

Some languages restrict where block expressions can be placed, but that's not
a meaningful difference between if expressions and ternaries, that's a
difference how blocks are treated. More concretely: I know of no language that
allows "if expressions" that aren't just ternaries (i.e. either the language
allows blocks as expressions or it doesn't, but given that choice, no language
then further distinguishes between if expressions and ternaries).

------
merb
The only thing I find bad is that not everything is a expression.

~~~
rubiquity
That's my only gripe with learning Swift so far. I'm also shocked at how often
this document says "We do this to be like C" but yet I think the
features/ideas of Swift that come from the ML family (Option/Maybe, Enum/ADT)
are what makes Swift so great.

------
sdegutis
I saw this the other day and really appreciated it. It was a nice change from
how some other languages (WHO SHALL NOT BE NAMED) just say "no, we're not
adding this, and if you keep thinking we should then you're just not smart."
This Swift document on the other hand explains _thoroughly_ their reasoning
behind it.

~~~
_ak
The languages that you mean probably have this information somewhere, just
buried in some mailing list archive instead of compiled like this. Not that
people would stop complaining even with such readily available information.

~~~
cwzwarich
Some open source projects prefer to avoid discouraging prospective
contributors, even if they know that the task the contributor is currently
working on has no chance of acceptance. The hope is usually that avoiding
discouragement will build a larger community, and that contributors will
eventually realize the futility of their efforts or otherwise organically move
towards making productive contributions to the project.

~~~
briandear
What wacky logic. If I am going to spend valuable time helping a project only
to let the work simply be wasted, I will organically move to some other
project that values my contribution enough to not waste my time.

------
_RPM
I used Swift for a class and really liked it. It reminded me of a mix of
Python, C, and JavaScript which are my favorite languages. I hope to use it
more outside of Apple's hardware if it makes sense.

------
raverbashing
This reads mostly as "people wanting swift to be something different than what
it is"

~~~
weaksauce
Well in a sense that is swift-evolution.

~~~
raverbashing
I disagree, it's more like "my favourite X has this, so I want everybody else
to have it"

If Swift's idea was to be a C-like language then it doesn't make any sense to
suggest indenting as code-block markers, or to not use 'default' in switch
statements

~~~
weaksauce
It was only c like in brackets. This language is an amalgam of the good
features of many languages really and it's not done adapting to where it
should be. I agree that indentation from Python is a bad feature though.

------
cies
I think I kind of guess what would be the items on a similar list for Golang
would be (for instance generics being a no-no).

And I must say I _must_ prefer the stance Swifts developers take compared to
Go's situation. It is because of this that I think that Swift likely has a
great future competing with Go in the space of web-software; be it a bit in
the long run as it currently lacks some basic facilities/libraries.

I wish the both the best, for 2016 and beyond. But I keep a eye on Swift's
web-tech libs as I expect it to blow up in the coming years :)

------
cballard
Is there any explanation for the lack of types in error handling anywhere? The
compiler should be able to _easily_ infer those and require that you handle
them correctly.

~~~
chrislattner
There is a proposal to add support for them - it is currently blocked on
infrastructure work necessary to "do it right".

~~~
cballard
Thanks!

------
bruxis
I haven't had a chance to work with Swift much yet, but I'm actually very glad
for their reasonings. The only issue I might gripe with is the single quotes,
but I get the unicode perspective.

~~~
weaksauce
How often are you really making characters? Single quote for unescaped string
literals is used way more often in my world and it's a feature of ruby, base
et al. and other languages. Character("X") isn't that bad for something used
minimally.

~~~
yeukhon
I argue that even in the case of char, why so cheap now to reserve a type for
char instead of using unicode? I get it, sometimes you have requirements where
char type is cheaper to use, but on iPhone a few extra bytes won't kill.

~~~
weaksauce
well it's supposed to be a systems language so it makes sense to have all
types available. you could ask the same of Int8 being in the language when
pretty much all processors nowadays are 64bit.

