Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us money per month for bills, and since we don't believe in showing ads to our users, we try to make the money back through forum registrations.
 
  • Locked thread
b0lt
Apr 29, 2005
Why is the lambda syntax so weird? Why make in a keyword in the first place, instead of just using C++/java style foreach syntax?

Adbot
ADBOT LOVES YOU

b0lt
Apr 29, 2005

rjmccall posted:

Swift is a fully statically-compiled language with a minimal runtime which can interoperate trivially with C and, eventually, C++. That's a language niche that we believe is very poorly filled right now. Languages with comparable expressivity to Swift overwhelmingly come attached to massive managed environments which "natively" wrap or reimplement half the operating system.

We have a very solid ABI stability design; it just didn't make the implementation cut for 1.0 because library development had to take second seat to app development. (The design is largely validated in its technical direction because it's the same implementation design that enables our generics model.)

Objective-C offers relatively little to a programmer who doesn't have a massive library of Objective-C classes to use. It's basically just a class syntax, and people can muddle through with C++.

How do you interop with C trivially when there doesn't appear to be a pointer type in the language?

b0lt
Apr 29, 2005

rjmccall posted:

We can live with criticism. I apologize for giving you the impression that we decided this basically on a whim; there were literally weeks of iterative discussion, implementation, and feedback about exactly this topic, and we've considered every single possible option ad nauseam, including dropping either or both operators. After much debate, our conclusions were that:

1. When the upper bound isn't constant, people pretty much always want the half-open range.
2. When the upper bound is constant, people find the half-open range a little weird.
3. #1 dominates #2 in actual code.
4. When people think about the operators consciously, they tend to think about a constant upper bound.
5. Because of #3 and #4, people tend to consider the operators as equally important.
6. Because of #5, if we only provide one operator, people have trouble remembering which operator we actually provide.
7. The confusion of having both is actually pretty minimal if something immediately reminds you which one is which.
8. The "more dots is more numbers" mnemonic is both obvious and potent.
9. People using existing languages that don't follow the obvious mnemonic seem to have trouble remembering which is which.
10. #9 is probably caused by being contrary to the obvious mnemonic.
11. Because of #9, the power of precedent is pretty weak.
12. These operators are pretty useful in practice, especially the half-open range.
13. Because of #6, we have to provide both if we're going to provide either.
14. If existing precedent is weak, we might as well do the right thing, let the mnemonic reinforce the right pattern, and have them be confused only if they go back to Ruby.

Or you could use something other than dots, e.g. x until y, x to y.

  • Locked thread