|
me: tr Xcode: May I suggest TRUE? me: tru Xcode: Surely you mean dylib's TRUE macro and not the swift boolean literal. me: true Xcode: I knew it! Fixed it for you. Swift: 'DYLD_BOOL' is not convertible to 'Bool' Xcode: Man, you suck at this me:
|
# ? Apr 3, 2015 20:45 |
|
|
# ? May 14, 2024 04:45 |
|
me: UIColor *color = [uic Xcode: I know! UICollectionElementKindSectionFooter! me:
|
# ? Apr 3, 2015 21:04 |
|
me 99% of the time: me: tr Xcode: ... me: tru Xcode: ... me: true Xcode: ...
|
# ? Apr 3, 2015 23:05 |
|
it's a 4 letter word, by the time you react to the autocomplete box that comes up you've finished typing it I guess you were probably going for that point in a way.
|
# ? Apr 4, 2015 03:54 |
|
More like no autocomplete showing/working at all.
|
# ? Apr 4, 2015 16:28 |
|
It all depends on the file you're currently editing. The more lines of code it has, the more likely the autocomplete is crashing and burning in the background and unable to actually do anything useful for you (besides causing Xcode to crawl and throw random errors at you).
|
# ? Apr 5, 2015 04:33 |
|
It seems to be more of the size of the target than the size of the current file, since I've had no syntax highlighting/autocomplete on five-line files plenty of times.
|
# ? Apr 5, 2015 05:20 |
|
This code causes swiftc to crash with no error message:code:
code:
If any of you kids will be at the watch lab tomorrow I'll see you there. Simulated fucked around with this message at 09:03 on Apr 6, 2015 |
# ? Apr 6, 2015 08:58 |
|
It's a bug with using super in a closure or auto-closure; no need to file it, it's already fixed internally. (The RHS of a short-circuiting operator is an auto-closure.)
|
# ? Apr 6, 2015 21:33 |
|
Anyone else use Circle CI / Travis CI for your builds with tests? Getting a lot of hangups and time outs in our Swift solution. Happens in both xcodebuild and xctool and I'm kind of at a loss.
|
# ? Apr 6, 2015 22:01 |
|
Xcode webpage says 6.3 is about to land in the app store today.
|
# ? Apr 8, 2015 18:41 |
|
I wonder what, if anything, changed from the most recent beta.
|
# ? Apr 8, 2015 22:32 |
|
Just got xcode 6.3 and edit: Heyyyy do I have to always include argument labels, even for the first argument, in extensions and class functions? I have some extension methods where there's only one argument and the meaning of it is obvious, so I would really like to be able to opt out of this. brap fucked around with this message at 02:08 on Apr 9, 2015 |
# ? Apr 9, 2015 01:12 |
|
fleshweasel posted:Just got xcode 6.3 and Ugh. fleshweasel posted:edit: Heyyyy do I have to always include argument labels, even for the first argument, in extensions and class functions? I have some extension methods where there's only one argument and the meaning of it is obvious, so I would really like to be able to opt out of this. Hmm? The first parameter name is never an argument label by default; you have to opt into that with something like func foo(x x : Int) or (equivalently) func foo(#x : Int). If you want to opt a later parameter name out of being an argument label, you give it an explicit argument label of "_", e.g. func foo(x : Int, _ y : Int). But that's the default for the first parameter of a method. (For a non-method, nothing is an argument label by default.) I personally think this is dumb, and several of us would prefer to make it something more consistent like "all parameter names are argument labels by default", but this is where we are right now for complex political reasons.
|
# ? Apr 9, 2015 02:50 |
|
Are there non-obj-c reasons for the first argument being different? It makes sense for calling obj-c defined things since you'd need some crazy heuristics to split the method name from the first argument label, but not so much for pure Swift.
|
# ? Apr 9, 2015 03:18 |
|
rjmccall posted:I personally think this is dumb, and several of us would prefer to make it something more consistent like "all parameter names are argument labels by default", but this is where we are right now for complex political reasons. Would it be worth filing a radar if I feel strongly about particular default argument label schemes?
|
# ? Apr 9, 2015 03:46 |
|
Plorkyeran posted:Are there non-obj-c reasons for the first argument being different? It makes sense for calling obj-c defined things since you'd need some crazy heuristics to split the method name from the first argument label, but not so much for pure Swift. I'll just innocuously observe that, as you say, ObjC doesn't separate the first argument label from the method name, and C does not label arguments at all. pokeyman posted:Would it be worth filing a radar if I feel strongly about particular default argument label schemes? Absolutely.
|
# ? Apr 9, 2015 04:49 |
|
I have some extension methods like Array.any(predicate: T -> Bool) -> Bool which are now demanding I include the predicate: part. Also, the time it takes my app to deserialize a few hundred objects on an old phone has been cut in half. So thank you Swift team for the speed improvements. edit: I'm guessing this is in part related to the simplification of my validation process thanks to the new if-let, let, let... feature. So thanks for that too. edit again: I realized the issue. Functions with optional arguments now require those optional arguments to be labeled whenever they're included. So I can call .any() with no argument and it essentially returns the same value as array.count > 0. Or I can provide a predicate and it will tell me if any of the elements return true for that predicate. edit once again: Buttttt if that argument happens to be an inline closure I can put it outside the parentheses and not include the label. So I'm sure it's really fun arguing about these rules over there. brap fucked around with this message at 05:25 on Apr 9, 2015 |
# ? Apr 9, 2015 04:50 |
|
Am I stupid for thinking this should work?code:
Simulated fucked around with this message at 18:21 on Apr 10, 2015 |
# ? Apr 10, 2015 01:05 |
|
+ ?
|
# ? Apr 10, 2015 01:24 |
|
I upgraded to the App Store version of Xcode 6.3, and the compiler seems to be more strict with initializers now than it was in the beta I was previously using. In my app, it's a common pattern to create NSViewControllers programmatically, so the failability of the designated initializer init?(nibName: String?, bundle: NSBundle?) is inconvenient since I'm not actually loading the view controller from a nib. I have a base view controller class that my other view controllers inherit from, and I was previously able to make a convenient non-failable initializer with the following setup:code:
So my question is, is it possible to create a non-failable initializer in an NSViewController subclass? Or more generally, for any class whose superclass has only failable designated initializers? My instinct is that it's not possible, but I'd like to be able to do something like this: code:
code:
|
# ? Apr 10, 2015 05:34 |
|
Ender.uNF posted:concat Not sure about any other issue, because I'm not in a position to test the code, but you shouldn't keep calling next() after it returns nil. Swift Documentation posted:mutating func next() -> Element?
|
# ? Apr 10, 2015 12:05 |
|
Yeah, ends up I should just be using the + operator anyway. My question was specifically why the generic constraints fail though. Why can't Array<T> satisfy the SequenceType constraint? Array is a SequenceType and the where constraint should satisfy tiddlyWinks. code:
Simulated fucked around with this message at 18:22 on Apr 10, 2015 |
# ? Apr 10, 2015 18:05 |
|
Your global tiddlyWinks takes two arguments of the same type, and S is not necessarily the same type as Array<T>. If you want it to take sequences of two different types, you will need to writeSwift code:
|
# ? Apr 10, 2015 19:30 |
|
dizzywhip posted:So my question is, is it possible to create a non-failable initializer in an NSViewController subclass? Or more generally, for any class whose superclass has only failable designated initializers? My instinct is that it's not possible, but I'd like to be able to do something like this: You should be able to do this, but you can't, because we haven't implemented it yet. Sorry.
|
# ? Apr 10, 2015 19:37 |
|
fleshweasel posted:Just got xcode 6.3 and
|
# ? Apr 10, 2015 23:02 |
|
Two questions. First, if two types are typealiased to the same thing, is there a way to have the compiler show a warning or error if you try matching them? In other words: code:
As to the why: just because I have two types that are both actually Ints under the hood doesn't mean I think that adding them (or having them interact) is actually sensible. For example, if x represents the number of dollars you have on your body, and y represents the number of goal tokens you've obtained (and defining them as new structs seems odd because in all other ways I want them to work exactly like Ints, and I don't want to have to redefine +, -, etc. for each struct) Second, is there any way to "peek" inside of a curried function to find out what the bindings were? To use the example everyone seems to love: code:
As to the why: if I'm passing around a curried function, especially one where one of the values was computed elsewhere, it would be nice to be able to get that value so that I could print it out onto the screen, or more importantly, confirm it in a test. That way, I could actually be typealiasing functions as types and passing them around like first-class citizens, but also be able to query them and test them as value objects like first-class citizens.
|
# ? Apr 11, 2015 00:13 |
|
rjmccall posted:Your global tiddlyWinks takes two arguments of the same type, and S is not necessarily the same type as Array<T>. If you want it to take sequences of two different types, you will need to write The original version did use two separate types but the shadowing makes sense.
|
# ? Apr 11, 2015 03:15 |
|
What was the team's thought process in using "final" on classes and methods to prevent overriding and allowing it by default instead of using "virtual" to allow overriding and preventing it by default?
|
# ? Apr 11, 2015 18:08 |
|
You still need final even with virtual, so it's not really an "instead" thing.
|
# ? Apr 11, 2015 21:50 |
|
Also, non-virtual methods are still overrideable; it's just that the overriding is broken because it isn't polymorphic. There's a core requirement on subtyping that basic semantics aren't supposed to change just because you're using a less specific type. Non-virtual methods break that. That's why final actually forbids overrides instead of just limiting dispatch from considering implementations in further subclasses (which would be perfectly implementable if anybody actually wanted it). (Now, it's true that, because Swift doesn't have multiple dispatch, programmers can break substitutability by doing evil things with overloading. But that's a problem independent of of subclassing: if overlapping overloads have different semantics, substitutability is broken, and the user should probably be designing their API differently. In contrast, failing to automatically dispatch to the subclass's implementation is much more of a basic language failure.)
|
# ? Apr 12, 2015 02:11 |
|
King of Gulps posted:I had some SJW <BS> in mine This was pretty funny
|
# ? Apr 13, 2015 14:26 |
|
swiftc is written in C++... is there any reason that it doesn't catch exceptions and bail on processing a section of code (or a file) if it blows up? I find so many instances on a daily basis where I get the SourceKit crash because I'm modifying a piece of code and the syntax is temporarily invalid or nonsensical, or the types are jacked up for a moment while I fix it (It seems especially sensitive with generic types). To whoever on the Xcode team added the "Report a bug" link... So close, yet so far... I have to open console and find the bug report myself then upload it via the website. I just re-typed a bug report four times due to accidentally dropping crash reports in the wrong location, causing Safari to helpfully open the crash report and thanks to the design of bugreport.apple.com all my entered data was wiped (sorry bub, I don't auto-save until some arbitrary time limit has passed; not like we can afford some servers around here and do fancy stuff like saving every 5 seconds. Who do you think we are, the SomethingAwful forums?). Oh and did you know if you try to upload more than 5-6 files bugreport.apple.com helpfully removes the "attach file" button, causing the next file drop to again open the crash report in Safari and wipe everything that was entered in the form? Every step in the process screams "don't file bug reports, give up, go away" Bug report was eventually filed because I refuse to be defeated by a computer edit: I know I complain a lot but I'm actually really enjoying writing swift code and the 1.2 updates have been really nice. Simulated fucked around with this message at 23:03 on Apr 19, 2015 |
# ? Apr 19, 2015 21:59 |
|
I'm not sure what you think would happen if SourceKit "handled" "exceptions" from the Swift compiler except something strictly equivalent to SourceKit crashes. I mean, Swift is asserting on your code, either that or crashing downstream of a !NDEBUG assertion; and it's being run in a subprocess of Xcode, and Xcode is reporting that its subprocess crashed. The fix is clearly to not trigger the assertion, or the invalid state behind it; short of that, I'm not sure what other recovery you think would be better, except maybe not using the word "crash" when reporting the problem, or not reporting the problem at all.
|
# ? Apr 20, 2015 07:01 |
|
rjmccall posted:I'm not sure what you think would happen if SourceKit "handled" "exceptions" from the Swift compiler except something strictly equivalent to SourceKit crashes. I mean, Swift is asserting on your code, either that or crashing downstream of a !NDEBUG assertion; and it's being run in a subprocess of Xcode, and Xcode is reporting that its subprocess crashed. The fix is clearly to not trigger the assertion, or the invalid state behind it; short of that, I'm not sure what other recovery you think would be better, except maybe not using the word "crash" when reporting the problem, or not reporting the problem at all. I was more curious than anything... when you know the current invocation doesn't necessarily need to produce SIL/LLVM IR because it's for use by the IDE why not just catch the assertion and see if you can continue to make forward progress? That means a red issue indicator instead of complete loss of any interesting IDE functionality. The huge assumption is it would even be possible to basically skip part of the AST (or automatically infer closing braces and so on) and still do something sensible, which may be way off-base... I'm not a compiler writer, I'm just going off what I've seen other compilers do with some seriously mangled syntax or byzantine constructions while still emitting at least some half-assed "sorry I saw dragons inside those braces, fix whatever you broke" instead of crashing. Big thumbs-up to the Xcode team (or interns?) for SourceKit being an extension though; despite the crashes I don't think I've ever lost a single line of Swift code even during beta. Separate question: Have you seen this before: code:
I don't even know how to start writing up a bug report on something like this. It would (quite rightly) get immediately poo poo-canned as vague and useless.
|
# ? Apr 20, 2015 07:50 |
|
It's probably something about the function you're stopped in that's terminally confusing LLDB's expression parser. If you can extract just it out to a standalone project, it might still happen.
|
# ? Apr 20, 2015 17:23 |
|
Any reason not to allow binding in a conditional even if not optional, so long as a where condition is included? It would save having to declare a useless temporary ahead of the conditional.
|
# ? Apr 20, 2015 22:16 |
|
We're looking into a major generalization of that syntax, actually.
|
# ? Apr 20, 2015 23:12 |
|
Hey congrats on being the 'most loved' language on the Stack Overflow survey.
|
# ? Apr 20, 2015 23:17 |
|
|
# ? May 14, 2024 04:45 |
|
I love that survey. Silly internet methodology aside, the "most loved" gloss is an insane misrepresentation of the original question asked of the survey-takers.
|
# ? Apr 21, 2015 00:24 |