Just one more thing - Swift thread - The Something Awful Forums

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Just one more thing - Swift thread

«‹›10 »

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

What is Swift?

Swift is a statically-typed, fully-statically-compiled, small-runtime programming language currently under development by Apple. Syntactically, it looks kind of like C except that most declarations start with a keyword like "var", "let", or "func" instead of a type name. So actually it looks a lot like Rust.

Swift code:

func fibonacci(n: Int) -> Double {
  if n <= 1 {
    return Double(n)
  } else {
    return fibonacci(n - 2) + fibonacci(n - 1)
  }
}

let n = 32
println("fibonacci(\(n)) = \(fibonacci(n))")

Swift provides a very rich set of types, including record types with inline storage (structs and tuples), algebraic data types (enums), and reference types (classes). It supports generic programming via protocol constraints, somewhat akin to C++'s concepts or SML's interfaces.

The Swift compiler is directly integrated with Clang, so Swift code can directly interoperate with C and Objective C by simply importing or exporting a header. C++ support is a goal.

If you are a PL geek, Swift's type system is essentially similar to Pierce's System F_<, except with limited user-defined conversions, which means it is actually quite different in some fundamental ways but never mind.

I would be happy to answer any questions you have about Swift here.

# ¿ Jun 2, 2014 19:45

Adbot: ADBOT LOVES YOU

# ¿ Apr 29, 2024 01:11

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

Is this under NDA?

No.

Is this open source?

Not yet. It probably will be, but I can't make promises. Right now, our repository still has a lot of history that we don't want to make public, and we have a lot of work to do before we release.

Your decision to parfolate the quanazores sucks, and you suck, too. In 1987, I was studying in Cypress with Don Woods when we decided to visit Mt. Athos, where . . . and then . . . Riemann integration . . . so the waiter said . . . quartic roots . . . anyway, the five of us finished the paper that night over the last of the hashish, and as I recall it clearly demonstrated that quanazore parfolation is deeply hosed up, and you should have consulted with us before ruining your language forever.

Nothing is ruined. Swift has not yet committed to any measure of source compatibility. Even for 1.0, we are only committing to produce tools that will (to the greatest extent possible) automatically update your code to be compatible with the 2.0 language. So we have plenty of time to consider proposals like this.

How do I iterate over all the values in an enum?

It's a great idea, and it's something we want to do, but we haven't had time for it yet.

rjmccall fucked around with this message at 06:14 on Jun 18, 2014

# ¿ Jun 2, 2014 19:46

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

I absolutely refuse to use your language because (check all that apply):

[ ] It's another loving object-oriented language.

You're in luck! It's another loving object-oriented language. OO is a pretty great tool for code organization and namespacing, and abandoning it would be dumb.

A lot of criticisms of OO are really about (1) the use of inheritance to achieve subtype polymorphism and (2) the abuse of subtyping to paper over other inadequacies in the language. We generally agree with both of those criticisms. Swift provides a rich protocol system which enables both subtype polymorphism (via existential erasure) and parametric polymorphism (via generic programming).

Swift also provides a single-inheritance dynamically-dispatched class system. There are two reasons for this. The first is that protocols are inherently awkward to extend, which makes them bad at modeling the reality of classes that frequently gain new functionality in library updates. The second is that it's totally mandatory: Swift has a hard requirement to seamlessly interoperate with languages i.e. Objective C) with a single-inheritance dynamically-dispatched class system.

[ ] It's another loving imperative language.

At its core, yes, the basic metaphor of a Swift function is a series of statements to run, and we provide all the familiar C-like structured control flow statements.

That said, we've found (and intended) that Swift encourages a fairly functional style, mostly because we've put a lot of effort into addressing various dumb things that push programmers towards an imperative style. Immutable locals are as easy to declare ("let") as mutable ones ("var"). Tuples and ADTs promote multi-value returns instead of out-parameters. Function values are convenient to create and work with. I think a committed functional programmer could do quite well if they can survive writing 'return' in a few places.

But there is still mutable global state, so maybe not.

[ ] It's another loving language with global mutable state.

Yep. We have zero interest in making a programming language that can't support the basic infrastructure for GUI programming on our platforms. "You should be using FRP for that, let me cite you some papers" is not actually something we can work with.

[ ] It has significant whitespace.

It totally does. We didn't want a mandatory statement terminator/separator, so there you go. At least it's not indentation-sensitive.

The informal motivating theme behind the whitespace rules is to at least be able to tell programmers that the reason we misparsed their code is that their code style sucks.

'(' and '[' continue an expression if and only if they appear on the same line as the previous token. If you put a between a function and the start of its arguments, or between an array and a subscript, you deserve what you get.
An operator is a binary operator if and only if it is "bound" equally on both sides. An operator is bound on a side if the next character in that direction is something other than whitespace, a comma, or a closing delimiter. So "a + b" and "a+b" are binary, but "a+ b" is postfix and "a +b" is prefix. It's also illegal to put multiple statements on one line without a semicolon, so to actually get misparsed here (instead of just getting a parse error) you have to write something really, really questionable.

[ ] It doesn't have garbage collection in TYOOL 2014.

Garbage collection is a fractal of systemic problems.

GC is pretty awful for memory usage. All the sophisticated GC techniques to minimize pauses and improve locality seem to push up peak memory usage, often by quite a lot, which then evicts a lot of stuff that the system generally had a good reason to keep around.

GC is not friendly to static compilation. Many GC algorithms need to do bookkeeping on every store of a reference. To statically compile, you either have to commit to a lot of bookkeeping details as ABI, or you have to emit every store as a runtime call. You can get great performance if you JIT-compile everything, but that comes with its own host of problems.

GC adds massive nondeterminism. Good luck reproducing the conditions that led to that particular memory problem if your program isn't 100% native.

GC prevents naive interoperation with any language that isn't sharing the GC heap. Simple conservative C collection works (and sucks), but can't be soundly extended to languages with finalization (i.e. all of them) without explicit and unnatural efforts to preserve objects while operating on their dependent data.

rjmccall fucked around with this message at 19:48 on Jun 2, 2014

# ¿ Jun 2, 2014 19:46

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

It'll be useable in production. It still has a lot of room for improvement, but we're supporting it as a first-class language.

The main limitation here for practical development is that we're not promising source compatibility in 1.0.

# ¿ Jun 2, 2014 19:54

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

It's not like we're dropping Objective C. We think Swift is a pretty great alternative, and we'd like it to eventually be center of development on the platform, but obviously there's a massive amount of code written in Objective C, and not only do we want to continue supporting that, but we also want to support seamless interoperation with it.

# ¿ Jun 2, 2014 20:02

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

Doctor w-rw-rw- posted:

Neat. How long has this been under development?

About three years. Chris had hacked up a parser and crappy type-checker, but I was the first full-time developer/designer. The language has changed a lot since that prototype.

Doctor w-rw-rw- posted:

Details on how generics work?

We can run generic code directly without instantiation; type metadata is passed so that you know how to allocate/copy/destroy arbitrary types.

# ¿ Jun 2, 2014 20:44

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

pokeyman posted:

So long as Swift isn't unceremoniously dropped in two years like garbage collection in Objective-C (feel free to comment on that if you want), I'm happy to jump in whole-hog.

It's something that management believes very strongly in, and we're getting a lot of support. I think the odds that it'll be unceremoniously dropped are negligible.

The politics around GC were always very different.

pokeyman posted:

Presumably since it's the same runtime and ABI (? or a transparent FFI) one could deploy compiled Swift on to old versions of iOS and OS X?

We need a runtime on top of what the OS provides, but yes, we support deploying to at least the current set of OSes, and it's likely that someone could very easily make that work further back � la PLWeakCompatibility.

# ¿ Jun 2, 2014 20:54

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

Suspicious Dish posted:

What advantages do you think Swift provides over Objective-C?

A better type system along a number of axes. Pointers are non-nullable, structs are equal citizens, tuples obviate a bunch of crap, there's a generics system, etc.

The syntax is also a lot cleaner.

# ¿ Jun 2, 2014 20:59

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

Plorkyeran posted:

How do generics handle min(5, 5.1)? Mandatory casting to make the type inferrable?

Literals are overloadable with a default type. If the context suggests a better type, we'll use it; otherwise, we'll end up defaulting to Double.

# ¿ Jun 2, 2014 21:02

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

Doh004 posted:

I'm interested. But I'm curious as to why?

We think Objective C is showing its age and don't feel that any other language really does what we want. Rust is pretty close, except for the memory model and the fact that we had (have?) no reason to think it wouldn't be an eternal research project three years ago.

# ¿ Jun 2, 2014 21:06

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

Geno posted:

I've been thinking of messing around with iOS apps. Should I just start with Swift and not bother with Obj-C?

It's up to you. Learning Objective-C won't hurt. You'll mostly need to learn the APIs, and what you learn there will apply across languages.

# ¿ Jun 2, 2014 21:21

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

horse mans posted:

The keynote mentioned that Swift does away with 'entire classes' of programming errors. Could you elaborate on that a bit?

There's a bunch of things in this area. Our class pointer types are not nullable, but you can use a (very syntax-advantaged) optional type to add null back in a controlled way. We require variables to be "definitively initialized" before use, using a rule very similar to Java's but applied even to instance variables. Our equivalent of id does not implicitly convert to arbitrary types, although you can still call an arbitrary method on it with pretty minimal fuss. Generics don't define away dynamic type errors, but they can work to make them substantially less likely. Things like that.

# ¿ Jun 2, 2014 21:28

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

spongeh posted:

Friend didn't see any mention of how threading or concurrency works in Swift in the book. Is there any word on how this is handled yet?

It's something we want to put more language design work into, but frankly there were higher priorities. Right now, the story is pretty much the same as Objective-C, i.e. use GCD and other platform concurrency features.

# ¿ Jun 2, 2014 21:29

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

Siguy posted:

This is very impressive. Congratulations on having your work featured on pretty much the biggest stage possible.

Thanks! We're all pretty excited.

Damiya posted:

I'm not an iOS dev, so maybe this is a dumb question, but since there's no GC does that mean all memory management has to be done by the programmer?

No. Like Objective-C ARC, Swift has automated memory management using reference counting. You can think of it as a deterministic GC that's too stupid to collect cycles. Cycles can be manually broken using a weak reference or by explicitly reassigning one of the links in the cycle at a point when you know that's safe.

# ¿ Jun 2, 2014 21:33

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

JewKiller 3000 posted:

It may be better than Objective-C, but from a broader perspective (comparing to all languages), I don't see the big deal here. None of the features you've mentioned in this thread were introduced in the PL literature later than the 1980s. What's so good about this new language aside from making fewer mistakes?

We didn't set out specifically to appease language hipsters, nor are we submitting the language guide to POPL. I personally feel that making fewer mistakes is an admirable goal. Plenty of new languages with more interesting research pedigrees do not, in fact, succeed at making fewer mistakes.

Ultimately, it is just a programming language. Its value is as a tool, and it deserves to be judged on those merits.

# ¿ Jun 2, 2014 21:43

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

b0lt posted:

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?

It's not how I would have defined it, but I don't win every language design argument. I, personally, would probably just use a local func for anything that I thought was complex enough to merit a type signature.

# ¿ Jun 2, 2014 21:47

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

Suspicious Dish posted:

This is a big pet peeve of mine for new projects. Do you have any internal projects using Swift yet? New apps, new frameworks, whatever? I find that a lot of these PLs sound great until you actually go to use them, because nobody actually used them in the real world yet.

I am not going to touch Swift until I hear that you have a moderately sized, going-to-production codebase written in it.

That's understandable. We have some internal things ported, and we've been actively iterating on the design for about half a year with feedback from various dogfooders, but no, we haven't, like, rewritten Mail from scratch in it or anything.

# ¿ Jun 2, 2014 21:50

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

Ender.uNF posted:

No, it uses ARC so it more or less statically analyzes the code to produce the correct set of retain/release calls.

Are closures blocks? If they are first-class in Swift, then can I interrogate a block to determine its type arguments at runtime?

All the information is there dynamically, but we don't have the language machinery to actually bind a local type variable. It's likely that what you want to do could be achieved with generics, though.

Ender.uNF posted:

Speaking of type metadata, it appears that variadic functions can introspect the number and types of arguments. That leads me to believe the Swift type system is fully modern and you have full type fidelity at runtime for anything, including generics and the constraints.

You can write a function that takes a variadic number of values of any type; they'll be passed to the function as an array. You can, of course, dynamically ask an array for its size. The empty-protocol type Any can accept arbitrary values and carries the actual type in its representation.

Ender.uNF posted:

Is there any reason you went with a syntax-block-ish syntax for closures instead of the fat arrow? I believe ES6 adopted the C# fat arrow as well, given the influence of those two languages I was a bit surprised to see Swift takes a different route. The positional $ params are a cute trick though.

I think the concern was with parsing a parameter clause in an expression context. I dunno, I disagreed with it. You can file a bug saying that you hate the syntax; maybe it'll get changed.

Ender.uNF posted:

Can I export functions to C or objects to Objective-C from Swift? And how would that manifest given the simpler type systems?

Yes. You just can't export something whose type is not expressible in C/ObjC.

# ¿ Jun 2, 2014 22:00

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

ufarn posted:

Indeed, grats on shipping.

I don't know if this is your wheelhouse, rjmccall, but do you have any plans regarding community outreach and cultivation?

We do, but as you say, it's not my wheelhouse.

# ¿ Jun 2, 2014 22:00

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

lord funk posted:

You use true and false instead of YES and NO. I liked YES and NO.

You can get them back if you feel really raw about it.

Swift code:

var YES: Bool { return true }
var NO: Bool { return false }

# ¿ Jun 2, 2014 22:01

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

JewKiller 3000 posted:

Well OK, but where is Apple trying to position this language in the market? Do you expect that, like Java and C and Python, Swift will be used all over the place in many different environments... or do you see it more like Objective-C, a language that is technically just as general-purpose as the others, but in reality is used only by developers for Apple platforms? I'm not trying to push language hipster crap for its own sake, but if I don't see anything here that I can't get from languages I already know, then I'm not going to invest the time into learning a new tool.

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++.

# ¿ Jun 2, 2014 22:21

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

nebby posted:

How does it feel to know you are about to be the recipient of the largest motherlode of bikeshedding arguments in the history of computing?

Awesome. It feels awesome.

nebby posted:

edit: Serious question, probably one you can't answer, but how is Apple positioning this for adoption internally? Are all teams going to have the option to use Swift instead of ObjC? Are certain teams already planning on moving to it for all future development? Etc. Etc. I find it a bit surprising that this got released without a flagship app already being built in it as a proof of concept.

Rewriting a flagship app is basically just introducing massive risk to the development cycle of the flagship app. That would be true even if we were just rewriting it in the exact same language as before. The language is mature enough that we've been writing some internal apps in it and are now willing to open it up for public discussion.

You're correct that I can't talk about future product cycles or internal positioning.

# ¿ Jun 2, 2014 22:29

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

Axiem posted:

Any idea on a timeframe for a 1.0 release for those of us who want to do practical development in Swift?

I can't answer that more specifically than "I'm pretty sure it'll be this year", sorry. That is probably over-conservative.

# ¿ Jun 2, 2014 22:30

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

nebby posted:

Oh, another question. Where did you guys come down on macros/DSLs? I haven't read any documentation yet but it sounds like there aren't any facilities to extend the language. A huge bummer coming from someone who uses RubyMotion and has seen the benefits. (Though I acknowledge that it has its downsides.)

It depends on what you mean. We don't allow you to define your own true statements, and we don't have a true macro system, but you can do quite a lot of "language extension" within the existing expression syntax via generics, trailing closures, auto-closures, and custom operators.

I think we'd like a proper (hygienic, Scheme-like) macro system eventually.

# ¿ Jun 2, 2014 23:10

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

b0lt posted:

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

There's a generic UnsafePointer type, we just intentionally didn't privilege it with syntactic sugar.

double sulk posted:

Did Scala have any level of influence on Swift? It seems like there's that kind of a vibe but it could just be me.

We're generally aware of Scala, but I don't remember borrowing anything specifically from it. Frankly, I think your vibe might mostly be a "everything looks like something in Scala because Scala has no sense of shame" thing.

usdachoicemustache posted:

A lot of decent decisions overall.

The treatment of dictionaries and arrays seems ripe for headaches, though. Oh you used let, that means you can't change the collection either, except you can (in some ways) if it's an array. I suspect those rules are to maintain performance or ease of bridging or something, but it seems unnatural to have that rather than allow separate specification of constant|mutable reference & constant|mutable collection.

Arrays used to be a pure value type, but there was some performance panic about it at the last minute. It's likely something that we'll iterate on.

rjmccall fucked around with this message at 23:16 on Jun 2, 2014

# ¿ Jun 2, 2014 23:11

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

Ender.uNF posted:

Why can't Any contain a function? Is there some reason not to treat functions as first class objects?

It's just a bug. We're already tracking it.

I'll mention custom operators in :siren:

my talk

, and I'm pretty sure they're covered in the guide, but essentially you just declare the operator somewhere in the program:

Swift code:

operator infix|postfix|prefix %%% {
  // You can skip these and Swift will just complain if you ever write this next to another binary operator.
  // associativity left|right
  // precedence some-magic-number
}

And then you define a global function with that name:

Swift code:

func %%%(a: Int, b: Int) -> (Int,Bool) {
  // whatever
}

(Advanced Swift, Thursday at 11:30)

# ¿ Jun 2, 2014 23:37

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

haxored posted:

Since it was so widely publicized, Swift is probably the name Apple are sticking with. I am curious if there was much contention over the name given the existing project at http://swift-lang.org

We did work out something with them; I don't know the details, other than that we agreed that they could keep the domain and that we'd link to them from our site, which we do. If we go open-source, I assume the main site will be swift.llvm.org.

# ¿ Jun 3, 2014 01:06

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

Plorkyeran posted:

On the Xcode side of things it'd be nice if the warning about it inferring AnyObject suggested adding a cast rather than explicitly annotating as AnyObject, especially for for-int loops since it wasn't totally obvious I could just cast NSArray to Foo[] in the loop header.

Good idea, filed.

# ¿ Jun 3, 2014 01:35

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

tef posted:

How hard has it been to keep quiet about this for what seems a long time?

Slightly over three years.

It's usually not a problem; if people want to talk about languages, it's not like I can't keep up the conversation anyway. Sometimes people will smuglord about Objective-C to me, which is a great opportunity to quietly stew / feel superior. Probably the most frustrating thing is having to tell some C/ObjC developer (internally, or on a mailing list, or at WWDC, or here) that hmm, yes, modeling multiple return values with tuples seems like a very interesting idea, but unfortunately we're totally booked right now, maybe we'll take it under advisement for a future release, please file a bug so you can track progress.

tef posted:

- How about a meta object protocol? I can't see how a class would define behaviour under 'for-in' loops ?

Declaring that type objects conform to a protocol intended for instances is an interesting question, because it's simultaneously (1) abstractly reasonable, (2) maybe somewhat marginal in value, and (3) sets off my "this is going to cause problems" instincts something fierce, although I'm not sure why.

If we wanted to support it, it would probably be with syntax like extension MyClass.Type : Whatever.

tef posted:

- You have string interpolation, but no string formatting (yet?)

We had something in place to allow string interpolations to modify the output and ultimately decided that that wasn't actually a very good idea compared to just having global hex functions that change the output, or using some existing printf-like API.

tef posted:

- Do you normalize unicode identifiers?

I think we discussed it and decided that not normalizing was the right thing to do. IIRC, the problem is that locale-insensitive normalization is often not good enough, but making the compiler locale-sensitive would be a terrible idea.

tef posted:

- Will there be named versions of .. and ... because i'm poo poo at remembering the difference.

You can just directly construct the range types.

If you want to try to remember the difference, we decided to deviate from Ruby precisely so that the one with more dots would be the one with more values. We were consistent with Ruby for awhile but kept getting feedback like "Yeah, the way I remember this is that it's the exact opposite of the way I think it should be."

tef posted:

- Can't see any handling for runtime errors beyond option types, like exceptions. Did I miss something?

We have some really vague design points here, but we ran out of time for this release; the political reality is that we needed to make Cocoa feel really great so that we could get the space to do other things well. I think we want something that'll feel kindof like checked exceptions, but maybe with a unified error type and different expectations about how they'll be used (and possibly not using stack unwinding). But this is still up in the air.

tef posted:

But mostly, there are a lot of nice bits. Integer overflow protection, explicit casts between numeric types, no old style octal literals, underscores in numbers. Enums and match show a lot of thought. This is something other languages should steal.

Thanks!

tef posted:

My main problem is really waiting for open source/non apple targets or environments.

Yeah. The basic schedule I'm expecting / hoping for is "get 1.0 out the door, clean up the repository, release to open source", but of course, it's not my call.

# ¿ Jun 3, 2014 02:36

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

Plorkyeran posted:

String(format: "stuff %02X", 5) works fine. The documentation of the standard library current only mentions things different from obj-c (and not even all of that).

The standard library documentation is definitely something we're working on.

neurotech posted:

For the uninitiated, who is rjmccall with regards to connections to Apple? Is it public knowledge or more of a 'I cannot say' thing?

It's pretty much all public because I literally post under my college (and thereafter standard) username. I'm John McCall, I work in the programming languages group at Apple doing compiler development and language design.

# ¿ Jun 3, 2014 02:44

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

Ender.uNF posted:

Tried to make some notes instead of posting piecemeal.

1. Mutability of let array is really ugly, unintuitive, and horrible. Introduce proper syntax for it.
2. The copying behavior is even worse

We'll be looking more closely at arrays, I think. Please file a bug; I think you're misunderstanding what we're even trying to do with arrays, and that's probably yet another indicator that what we're trying to do is too clever by half.

Ender.uNF posted:

3. Dictionary�s passing also sucks
4. Seriously guys, just do real copy on write arrays/dictionaries and support a fixed size array syntax directly; then we can get real immutable vs mutable collections.

Dictionary is copy-on-write. At least, it's supposed to be. What are you seeing?

Ender.uNF posted:

5. Closure capturing self, still ugly as sin � can�t we solve this problem? Some way to say if a closure is stored on an object and references self, then on every release of the closure or parent we check both to see if the only remaining live references are each other. ARC�s biggest flaw.

That doesn't actually scale to two closures on the same object. Ultimately, this is just asking for cycle detection.

Ender.uNF posted:

7. Why don�t extensions just use the underlying associated object functionality to let you transparently add stored values?

It's a reasonable feature (when extending class types, at least) that we've designed but haven't implemented yet.

Ender.uNF posted:

8. Since we can�t do performSelector, what�s the alternative for stuff like performSelector:afterDelay:?

Is dispatch_after not good enough?

Ender.uNF posted:

checked exceptions - please no...

I probably shouldn't have said anything. "Checked exceptions" is misleading even for what we're thinking about, and frankly we haven't thought about it deeply enough that I have any business publicly speculating.

# ¿ Jun 3, 2014 02:58

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

Plorkyeran posted:

Normalization doesn't have anything to with locales. Case-insensitive identifiers would require locale-sensitivity unless you're willing to pretend Turkey doesn't exist, but converting everything to NFC or NFD inherently doesn't involve any change in semantic meaning.

My Unicode is not very strong. I understand that there are normalizations you can do which would unify some strings, and we should probably at least be doing those. The question is whether (case-sensitive) string equivalence is actually locale-insensitive, because that's what I would expect name lookup to use in a maximally Unicode-aware world.

# ¿ Jun 3, 2014 03:21

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

Ender.uNF posted:

The docs seem to be saying that passing a dictionary passes a copy, but arrays are by reference. It also seemed to say that an immutable instance of array is not really immutable, it's just got a fixed length, but immutable dictionaries are really immutable.

That's all correct in the current model.

Any particular variable, mutable or not, stores a value. For a true value type like Dictionary, everything about it is part of the value, and when you copy it around, you are always getting an independent value. Our Array is currently not fully a value type, in that it has partial reference semantics: copying it around does not give you an independent value. Only performing an operation with the potential to change the size of the array will force a particular array to acquire an independent value.

If you find this confusing, your feedback would be really valuable. Unfortunately, *you* have to provide that feedback; it's not as valuable if I try to report it second-hand.

Ender.uNF posted:

I get a bad feeling about the syntax of closures in general though because the argument list looks like a statement inside a block (not NSBlock) body. Everything else is declare the types outside the braces. Did someone do that so they could get the clever ability to stick the code of the body after the method if the closure is the last parameter? Not worth it. I'm going to break my rule about not filing radars just for you and file on this stuff.

Thank you. I think you're correct that trailing syntax was a major motivation for putting the argument clause inside the braces.

# ¿ Jun 3, 2014 03:54

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

Plorkyeran posted:

Yes, case-sensitive comparisons are locale-independent. Normalizing everything to NFC or NFD is basically the equivalent of converting everything to UTF-8 rather having strings in a bunch of different encodings. Pretty much everything else is locale-sensitive: case-sensitive comparisons are locale-sensitive because I and i are different letters in Turkish, accent-dropping is locale-sensitive because sometimes accents are just a pronunciation guide with no semantic meaning (as in co�perate), and sometimes they make letters into entirely different letters, and sorting is just different all over the place.

Okay. So as I'm understanding you, Unicode basically considers there to be two answers to this question. The real semantic property of whether two strings are the same in a human language must necessarily consider all sorts of things about case and accents in an intrinsically locale-sensitive way; for this, Unicode provides the standard collation algorithm, with all of its variants. Taking this property and saying "oh, but distinguish case" is basically ungeneralizable nonsense, so it might as well be defined by the equivalence of the sequence of grapheme clusters, which can be determined in a locale-insensitive way. And it's this latter thing that is most reasonable for a programming language to use.

# ¿ Jun 3, 2014 04:14

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

Suspicious Dish posted:

This seems to be a poor choice, especially since it's one of those dumb, incredible easy-to-miss mistakes that will bite people that the compiler can't catch. I'd only include one range constructor, and deprecate or remove the other syntax immediately.

You will get blog posts from people blaming Swift for subtly doing the wrong thing.

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.

# ¿ Jun 3, 2014 04:50

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

Infix identifiers introduce a lot of their own problems. We did consider ..< for a while.

Basically, if you want to understand the deep unsexiness of actual language design work, think about talking about loving range operators for thirty minutes straight in multiple consecutive design meetings, and then having endless mailing conversations about the same drat thing, and then have it all come up again six months later.

And then knowing you will be endlessly second-guessed about it.

# ¿ Jun 3, 2014 05:01

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

Axiem posted:

Also, is there any particular story you can tell on why a name that's going to be so impossible to google against was picked? Based on what I've read so far, the name is the thing I hate most about the language.

Product marketing made that call. I assume their thought process was that, if we can't beat the Society for Worldwide Interbank Financial Telecommunications by the end of the summer, we don't really deserve to have a programming language.

# ¿ Jun 3, 2014 05:08

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

Scaevolus posted:

Why would you need a++.b?

It's really about postfix ! and ?.

Scaevolus posted:

I can't find documentation on how newlines are handled semantically.

I talk briefly about this in one of the first posts. Basically, you can't split a call or subscript across lines. Unless you mean "what is the exact definition of a newline", in which case the answer is that either \r or \n counts as a newline; the exact newline count never matters.

Scaevolus posted:

Does Swift use Clang's modules system?

For importing Clang headers, yes.

Scaevolus posted:

Neat features: Explicitly opting into nulls. Implicit break / explicit fallthrough on switch statements.

Checked arithmetic operations return an error, but how can you handle it?

Hmm. We should definitely provide operators that return an overflow bit back. I'll file that.

# ¿ Jun 3, 2014 05:16

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

Meat Street posted:

Possibly-stupid question: can I for-in iterate through an enum, e.g. the Suit enum in the card examples?

It's a feature we've thought about. Feel like filing a bug to ask for it?

# ¿ Jun 3, 2014 05:39

Adbot: ADBOT LOVES YOU

# ¿ Apr 29, 2024 01:11

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

Axiem posted:

Looking at the Swift documentation, I don't see any reference to private/public methods. Is everything public, or am I just missing something in the documentation?

Everything is public for now. We expect to have basic access control for 1.0.

# ¿ Jun 3, 2014 06:06

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Just one more thing - Swift thread

«‹›10 »