|
I ported a few smallish classes from Obj-C to Swift to get a feel for it, and so far I'm a fan. The interop is pretty painless (the biggest issue I've encountered is that NSXMLDocument(contentsOfURL: self.baseURL, options: NSXMLNodeOptionsNone, error: &error) doesn't compile (because the constant's CUnsignedInt and it's expecting Int?)), and even just a dumb mechanical translation is a surprising improvement. Way less boilerplate everywhere even while keeping obj-c style naming thanks to type inference and no more initWith, no loving headers, and a lot of little annoyances like having to declare every single property as nonatomic are gone.
|
#
?
Jun 3, 2014 01:01
|
|
|
|
| # ? Apr 26, 2024 00:57 |
|
|
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 posted: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:20
|
|
|
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.
|
|
#
?
Jun 3, 2014 01:25
|
|
|
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. I'm sure you know this already but just in case: file a radar!
|
|
#
?
Jun 3, 2014 01:29
|
|
|
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
|
|
|
What do you think the timetable for swift adoption will be? Say, one/two/three years from now, what % of apps will be written in objective-c vs swift?
|
|
#
?
Jun 3, 2014 01:37
|
|
|
rjmccall posted:Awesome. It feels awesome. How hard has it been to keep quiet about this for what seems a long time? rjmccall posted:I think we'd like a proper (hygienic, Scheme-like) macro system eventually. - How about a meta object protocol? I can't see how a class would define behaviour under 'for-in' loops ? - You have string interpolation, but no string formatting (yet?) - Do you normalize unicode identifiers? - Will there be named versions of .. and ... because i'm poo poo at remembering the difference. - Can't see any handling for runtime errors beyond option types, like exceptions. Did I miss something? 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. My main problem is really waiting for open source/non apple targets or environments.
|
|
#
?
Jun 3, 2014 01:47
|
|
|
The iBook says println("Hello, world") should be it's own self-contained program but when I make a playgrounds file with just that it has nothing over in the "playground" What's up with that? In fact any print doesn't show up over there but when you declare a variable it does show up like it was being printed.
|
|
#
?
Jun 3, 2014 01:53
|
|
|
tef posted:- Will there be named versions of .. and ... because i'm poo poo at remembering the difference. One more dot = one more iteration!
|
|
#
?
Jun 3, 2014 02:15
|
|
|
tef posted:- You have string interpolation, but no string formatting (yet?) 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).
|
|
#
?
Jun 3, 2014 02:23
|
|
|
I'm not versed in Objective-C 
|
|
#
?
Jun 3, 2014 02:29
|
|
|
tef posted:- Do you normalize unicode identifiers? Nope! 
|
|
#
?
Jun 3, 2014 02:33
|
|
|
This is pretty exciting. I can't wait to get stuck into the language. For the uninitiated, who is rjmccall with regards to connections to Apple? Is it public knowledge or more of a 'I cannot say' thing? lord funk posted:
I would also like to know this.
|
|
#
?
Jun 3, 2014 02:35
|
|
|
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
|
|
|
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 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. 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. 6. Exceptions or conditions? a. If not, then how do we deal with Objective-C exceptions? (Looks like just inout of NSError) 7. Why don’t extensions just use the underlying associated object functionality to let you transparently add stored values? 8. Since we can’t do performSelector, what’s the alternative for stuff like performSelector:afterDelay:? Overall impression: excellent work, I'm very impressed! Edit: checked exceptions - please no... I've looked at LISP's conditions and there are some interesting bits there but I'm not sure that's the right way to go. Simulated fucked around with this message at 02:40 on Jun 3, 2014 |
|
#
?
Jun 3, 2014 02:36
|
|
|
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
|
|
|
Ender.uNF posted:Tried to make some notes instead of posting piecemeal. 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 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 posted: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.
|
|
#
?
Jun 3, 2014 03:01
|
|
|
rjmccall posted: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. as it is not an open project yet i imagine this will not be the last time you say this. quote: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. I like generators in python and use them a lot. I also like to be able to have different sorts of collections outside of the array/dict builtins. You can override other operators, but not 'foo in bar' (and yes i know it's actually for foo in bar). quote: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. http://unicode.org/reports/tr15/ Last time i checked this seemed locale independent. Although if you're using identifiers for module names, and using it to search the filesystem, well, you might have a fun time as HFS+ does it's own normalization https://developer.apple.com/legacy/library/technotes/tn/tn1150.html#UnicodeSubtleties quote: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. The c# team wanted to add checked exceptions, but they never surfaced. I'd rather see something like coroutines than real exceptions. quote: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. I am unsure of the politics, but i'm hoping for the best.
|
|
#
?
Jun 3, 2014 03:02
|
|
|
rjmccall posted:That doesn't actually scale to two closures on the same object. Ultimately, this is just asking for cycle detection. libextobjc's @weakify/@strongify is the least-bad solution I've seen in obj-c, and it's pretty bad.
|
|
#
?
Jun 3, 2014 03:09
|
|
|
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 posted: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. 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. quote:That doesn't actually scale to two closures on the same object. Ultimately, this is just asking for cycle detection. My assumption was that if the total number of blocks retaining self matched the retain count then you're locked in a cycle and can dump them all. My other assumption is that this is the common case because you're right, going any further down chains of objects is GC-style cycle detection. It's just one of those ugly wart things that gives me a bad feeling when I see it. Not a deal-breaker. 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. quote: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. Not your fault, I think I just had a reflexive reaction because every drat java method I see just says "throws exception". I hope your team can iterate and come up with something more elegant than "goto fail", but that more clearly expresses intent than catch(Exception ex). That's what I found interesting about conditions - a method could provide handlers further up the stack with some options for skipping an item, continuing past the error, aborting, etc. I think it turns out you almost never care about what the error is, you just need to know if its part of a loop so you an skip that item/try some alternate thing, it's something you want to await and retry, or if it's something that should unwind the stack and abort the operation with bounds that can gracefully transition the first two into the third if you can't make forward progress. Then separately you need filters or some such thing that can globally get the chance to log the error regardless of what lower layers are doing.
|
|
#
?
Jun 3, 2014 03:22
|
|
|
rjmccall posted: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. It's not about doing culture aware sorts or comparisons (eg where some culture considers A and Å to be equal but another does not). It's about the fact that you can represent è as Latin lower case e with Grave (one code point) or Latin lower case e + grave combining mark (two separate code points). I agree that Swift should pick one standard normalized form and stick with it. I also agree that you need a single cultural invariant comparison. Also to whoever used a bunch of Emojii in the docs: 
|
|
#
?
Jun 3, 2014 03:30
|
|
|
rjmccall posted: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." 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.
|
|
#
?
Jun 3, 2014 03:33
|
|
|
rjmccall posted: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:39
|
|
|
#swift-lang on Freenode is pretty active if anyone wants to stop by.
|
|
#
?
Jun 3, 2014 03:41
|
|
|
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. I'd love to see a language do something similar to a proper mathematical interval syntax for integral ranges. Granted, the expression (1, 5) is ambiguous as gently caress in a lot of languages, but why not do:
I'd even consider getting rid of the two that are open at the low end and just support [x..y) and [x..y], since those are probably most likely to be used, and it maps cleanly to the classical C for loop where you usually specify the strict lower bound as the initializer and the condition is either < or <= the upper bound. No idea if that would pose difficulties in the grammar, though. Anyway, I've always enjoyed your posts, rjmccall, and I was incredibly excited to see this announcement today. Awesome work, and congrats! This has easily been the best WWDC in years.
|
|
#
?
Jun 3, 2014 03:45
|
|
|
rjmccall posted: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. They're about combining characters, as some letters can be stored as 'ü' or 'u+umlaut'. There are other ones like ligatures too, which have standard forms. NFC, NFD. There is another version (NFKD, NFKC) to handle some semantic similarities, mapping ligatures to individual letters, and numeric sub/superscripts into normal numbers. quote: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. Case sensitivity is a different issue, and of course, unicode has a thing for this: casefolding
|
|
#
?
Jun 3, 2014 03:46
|
|
|
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
|
|
|
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
|
|
|
Is Swift going to be supporting unit testing and the like? My workplace is thoroughly in the TDD camp (as am I), and having a language that really supports it would be fantastic. 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.
|
|
#
?
Jun 3, 2014 04:44
|
|
|
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. 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 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: Or you could use something other than dots, e.g. x until y, x to y.
|
|
#
?
Jun 3, 2014 04:56
|
|
|
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
|
|
|
quote:If an operator has no whitespace on the left but is followed immediately by a dot (.), it is treated as a postfix unary operator. As an example, the ++ operator in a++.b is treated as a postfix unary operator (a++ . b rather than a ++ .b). I can't find documentation on how newlines are handled semantically. Does Swift use Clang's modules system? 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?
|
|
#
?
Jun 3, 2014 05:02
|
|
|
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
|
|
|
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. Hmm. We should definitely provide operators that return an overflow bit back. I'll file that.
|
|
#
?
Jun 3, 2014 05:16
|
|
|
rjmccall posted: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. Or just do what Google did with Go and search for "swiftlang".
|
|
#
?
Jun 3, 2014 05:22
|
|
|
|
| # ? Apr 26, 2024 00:57 |
|
|
Possibly-stupid question: can I for-in iterate through an enum, e.g. the Suit enum in the card examples?
|
|
#
?
Jun 3, 2014 05:27
|
|
