On Jun 5, 2014, at 10:04 AM, Dietmar Planitzer < email@hidden> wrote: The problem with the ‘..’ vs ‘…’ syntax is that it is very easy to overlook in a code review where one has been used when the other one should have been used because the dots occupy only a small amount of pixels on the screen which makes them hard to visually distinguish. Ruby has had this syntax for 20 years; I’ve been using it off and on since 2002 or so and can’t remember ever having had a problem with this, or reading about someone else complaining about it.
let x = 4;
To me there is nothing in that statement that would make it clear that we are actually defining a constant here.
IIRC, ‘let’ is pretty common in functional languages, for establishing immutable bindings. This goes all the way back to LISP (early ‘60s?) Swift has a lot of inspiration from functional languages.
it is misleading and incorrect as soon as you actually define a method. A function != method. Technically you’re correct that there are differences, but I really think you’re reaching here. For all intents and purposes a method is a special type of function bound to a class. Plenty of widely-used languages, like _javascript_, use ‘func’ or ‘function’ as syntax for both. Objective-C is the only language I can think of right now that uses different syntax for declaring methods vs. standalone functions, and that’s just an artifact of its extending C.
why not simply stick with the traditional ObjC and/or C/C++/Java style declaration syntax?
- (Int)foo:(Int)x {..}
Really? I’ve always considered this the cruftiest part of Obj-C syntax, and something that always bewilders newbies. It’s also extremely syntactically-ambiguous in a context where expressions could also appear, like a Swift REPL, which would seriously complicate the parser.
The reason why the bug found its way into the code and made it into the final product is because the author was interrupted when he wrote this code and he simply forgot to put the ‘* 2’ there when he resumed writing the code. But because semicolons are optional in Swift, the compiler did not complain. In ObjC the compiler would have reminded the developer that the statement is incomplete.
Again, plenty of languages like Python, _javascript_ and Go lack or don’t enforce trailing semicolons, and I’ve never run into a bug like this or heard someone complaining about it. (Personally I’ve spent about half my coding time in the past year using Go, and while I have complaints about that languages syntax, the lack of semicolons is not one.)
Strings are passed by value. The reason that the language manual gives for that behavior is that it does this for safety reasons so that a string that we pass to a method can not be accidentally changed by it. However there are some bad consequences and surprising behavior that results from this design choice:
This one does make me uneasy too. It does simplify the language not to have to have mutable/immutable class clusters, but it’s a big change from Obj-C, with which the language has to interact. (There’s also the weird discrepancy that strings and dictionaries are copy-on-write but arrays are pass-by-reference.)
—Jens |