|
A lot of posts on swift-evolution are terrible ideas. They're trying to have the language hold their hand when they can't type a method signature correctly. I for one don't want to have to type more keywords everywhere because of that. The complaints about "if I have a default implementation and try to override it but use the wrong signature" are slightly more reasonable, but are they not unit testing their code? That's like one of the most obvious things you should write a test for. Then you have the crazies going "String should be able to implement Collection three different ways at once!"
|
# ? Sep 21, 2016 14:14 |
|
|
# ? May 30, 2024 10:09 |
|
Avoiding mistakes and avoiding the need to implement stupid unit tests sounds like a great idea to me.
|
# ? Sep 21, 2016 18:39 |
|
I don't see the point since override exists already
|
# ? Sep 21, 2016 19:51 |
|
sarehu posted:Avoiding mistakes and avoiding the need to implement stupid unit tests sounds like a great idea to me. There's an inflection point where it no longer becomes worth it. I don't have any desire to have keyword soup on every line of Swift because people think everything needs to be explicit or else the code base is "fragile." Plus, they wouldn't be writing a new unit test for "did this method override this default protocol implementation". The unit tests they should already be writing in the first place for the type should catch "this method had the wrong behavior" if they incorrectly spelled a method in the implementation and it ended up not replacing the default. I'm sure there's a better solution to this problem than the current state of things, but many of the solutions being offered on the mailing list are myopic and not well thought out. (I'm fond of the idea that extensions that declare protocol conformance should only be allowed to define things in that satisfy that conformance, and possibly lower-visibility helpers used therein, but that's currently hampered by the fact that extensions can't have stored properties yet.)
|
# ? Sep 21, 2016 22:29 |
|
Except you should not unit test every method or every behavior. It's only good to do so when the probability times cost of a mistake is high enough to matter.
|
# ? Sep 22, 2016 02:30 |
|
Why would you make a default implementation that it was semantically necessary to override? I mean, I can see a refining protocol providing a more specialized default (maybe corresponding to added restrictions from the refining protocol), but I wouldn't expect that to be detectable from a unit test, except maybe at compile time. I think people really just want a different language feature completely.
|
# ? Sep 22, 2016 05:24 |
|
C# already did this the correct way. By default if the name matches it is selected as the protocol (interface) implementation. If you want to be fancy then you explicitly specify which interface you are implementing. The vast majority of programmers never have to think about it, but you have options if you run into a complex scenario.
|
# ? Sep 22, 2016 05:38 |
|
I'd agree with that ^^ I can see the problems they're trying to avoid, but I think peppering the code with noise is the wrong approach and would be much better solved by better intellisense once Apple have hired all the R# devs to work on XCode.
|
# ? Sep 22, 2016 10:22 |
|
Yeah, it just needs to be easier in the IDE to fetch the signature of some protocol you're trying to implement in a class. The purpose of a keyword would really just be to make sure you are actually implementing a protocol method when you expect to be implementing one.
|
# ? Sep 22, 2016 15:32 |
|
sorry wrong thread
TheReverend fucked around with this message at 22:54 on Sep 23, 2016 |
# ? Sep 23, 2016 22:49 |
|
I posted something in the Rust thread about enum layout that's equally pertinent to Swift, in case anybody cares about ABI-level stuff. If anyone's curious about how this will apply to Swift 4's ownership semantics, it's likely that we'll just weaken the derived-lifetime rule absent some specific attribute on a case / property.
|
# ? Sep 25, 2016 01:42 |
|
Anyone make the baby step to Swift 2.3? Everything compiles fine, but Xcode is reporting inline errors all over the place that are Swift 3 specific. Suggesting fixmes for warnings but highlighting as errors.
|
# ? Sep 28, 2016 15:03 |
|
That seems bad. Maybe there's something in your project that didn't get migrated and somehow thinks it's Swift 3?
|
# ? Sep 28, 2016 18:12 |
|
Kallikrates posted:Anyone make the baby step to Swift 2.3? Everything compiles fine, but Xcode is reporting inline errors all over the place that are Swift 3 specific. Suggesting fixmes for warnings but highlighting as errors. Shut off "Show Live Issues" in the General tab in preferences. It shows the issues as if you were on Swift 3, even if you're not. edit; anyone know why a switch clause would complain to me that it's not exhaustive when it is? I added some code after the switch that was triggering the "this will never be executed" warning, yet I couldn't compile because my switch apparently was not exhaustive. dc3k fucked around with this message at 18:22 on Sep 28, 2016 |
# ? Sep 28, 2016 18:19 |
|
dc3k posted:Shut off "Show Live Issues" in the General tab in preferences. It shows the issues as if you were on Swift 3, even if you're not. I agree that the fact that these diagnostics occur together is arguably misleading for people used to C-like switch behavior where an unmatched value just skips the entire switch. The unreachable-code diagnostic is triggered by examining the control flow graph, and because Swift requires an exhaustive switch, there isn't an "unmatched value" edge in the control flow graph leading past the switch. That is, assuming that all of your cases just return or something, the compiler is correct to tell you that the switch isn't exhaustive and that the code after the switch isn't reachable. So what's really happening is just that Swift considers your switch non-exhaustive. Ideally, the diagnostic would tell you what cases it thinks aren't handled; do you not see those? Can you post your code?
|
# ? Sep 28, 2016 18:41 |
|
rjmccall posted:I agree that the fact that these diagnostics occur together is arguably misleading for people used to C-like switch behavior where an unmatched value just skips the entire switch. The unreachable-code diagnostic is triggered by examining the control flow graph, and because Swift requires an exhaustive switch, there isn't an "unmatched value" edge in the control flow graph leading past the switch. That is, assuming that all of your cases just return or something, the compiler is correct to tell you that the switch isn't exhaustive and that the code after the switch isn't reachable. So what's really happening is just that Swift considers your switch non-exhaustive. Ideally, the diagnostic would tell you what cases it thinks aren't handled; do you not see those? Can you post your code? Ah, all of my cases do return, so the fact that it's saying its unreachable I don't have a problem with. It makes sense. But the fact that it's saying it's not exhaustive when I've covered the entire enum is what's confusing. code:
code:
|
# ? Sep 28, 2016 19:00 |
|
rjmccall posted:That seems bad. Maybe there's something in your project that didn't get migrated and somehow thinks it's Swift 3? I've double and triple checked, all projects/targets in the workspace have Legacy Swift support set. Attempting to re-run the migrator for swift 2.3 reports all projects containing swift as already migrated. A possible hint is If I re-run the migrator anyways I see warnings reported that my target specified SWIFT_VERSION is 2.3 but overridden by the Xcode TOOLCHAINS default value. No custom toolchains installed though so I'm not sure if it's related. The errors would make sense if the Xcode default would override the target or project specific setting in some circumstances.
|
# ? Sep 28, 2016 19:11 |
|
dc3k posted:Ah, all of my cases do return, so the fact that it's saying its unreachable I don't have a problem with. It makes sense. But the fact that it's saying it's not exhaustive when I've covered the entire enum is what's confusing. You're checking for cases of non-nil b with let b?, so you also need to cover cases of nil b.
|
# ? Sep 28, 2016 19:35 |
|
Toady posted:You're checking for cases of non-nil b with let b?, so you also need to cover cases of nil b. I guess I just have no idea how these fancy enums with parameters work
|
# ? Sep 28, 2016 20:48 |
|
dc3k posted:I guess I just have no idea how these fancy enums with parameters work It might clarify to remember that optionals are really enums that are either .some(T) or .none. Writing let b? in the case statement is equivalent to writing .some(let b). Therefore, to be exhaustive, you also have to handle the .none case.
|
# ? Sep 28, 2016 22:21 |
|
Can someone please tell me what the gently caress is going on here... I have a very simple problem. I want to turn a squareish picture into a circle... code:
|
# ? Sep 28, 2016 22:54 |
|
thegasman2000 posted:Can someone please tell me what the gently caress is going on here... Really more of a Cocoa question, but I would guess that setting an image on a UIImageView doesn't necessarily immediately change the view's frame size, so you're setting cornerRadius to something unreasonable like 0. Should be easy to see in a debugger.
|
# ? Sep 28, 2016 23:07 |
|
Kallikrates posted:I've double and triple checked, all projects/targets in the workspace have Legacy Swift support set. Attempting to re-run the migrator for swift 2.3 reports all projects containing swift as already migrated. It's supposed to track whatever scheme is currently active. If it's somehow using Swift 3 anyway, that's definitely a bug.
|
# ? Sep 28, 2016 23:09 |
|
rjmccall posted:Really more of a Cocoa question, but I would guess that setting an image on a UIImageView doesn't necessarily immediately change the view's frame size, so you're setting cornerRadius to something unreasonable like 0. Should be easy to see in a debugger. Sorry wrong thread meant to be in the apple dev one! That said the frame is 200 x 200...
|
# ? Sep 28, 2016 23:19 |
|
Is there something in the symantics around protocols/extensions that I'm missing here:code:
|
# ? Sep 29, 2016 18:59 |
|
Looks some weirdness in the order of operations or type constraints. code:
|
# ? Sep 29, 2016 19:13 |
|
Kallikrates posted:Looks some weirdness in the order of operations or type constraints. Weird.
|
# ? Sep 29, 2016 19:32 |
|
Trying Swift again. Swift won't let me "let x: Foo<Any> = something", where something is Foo<Bar>. Trying to wrap my head around a non-type-erased system. Am I doing something wrong here?
|
# ? Oct 3, 2016 07:22 |
|
Doctor w-rw-rw- posted:Trying Swift again. Swift won't let me "let x: Foo<Any> = something", where something is Foo<Bar>. Trying to wrap my head around a non-type-erased system. Am I doing something wrong here? Generics aren't covariant in Swift. Imagine that Foo<T> is a type that has a writable property of type T or a method with an argument of type T. The statement you're trying to write would assign a Foo<Bar> to a variable that would let you set a property or call a method with an Any when it's expecting a Bar.
|
# ? Oct 3, 2016 07:34 |
|
Flobbster posted:Generics aren't covariant in Swift. Imagine that Foo<T> is a type that has a writable property of type T or a method with an argument of type T. The statement you're trying to write would assign a Foo<Bar> to a variable that would let you set a property or call a method with an Any when it's expecting a Bar. Well, crap. Time to throw out the generics, then. I originally wrote the thing in ObjC then decided I wanted to try writing it in a way that would run on Linux too.
|
# ? Oct 3, 2016 07:46 |
|
code:
thegasman2000 fucked around with this message at 20:03 on Oct 6, 2016 |
# ? Oct 3, 2016 10:12 |
|
Starting to play with the swift package manager. Feeling pretty good about it so far, especially since it works well with Xcode. Are there any good Swift 3 command line parsing libraries?
|
# ? Oct 10, 2016 00:01 |
|
Coworker brought up this posting today: https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20160307/001384.htmlquote:we should not enable WMO for Debug builds. We don’t do any major optimizations on Debug builds and compiling things in WMO will only slow the compile times and not provide any speedups We just recently (today) enabled WMO on our debug builds, and noticed a drastic decrease in build times. Up until now, our build times have been loving insane. On a Mac Pro, clean builds used to take 20 to 25 minutes, and incremental builds anywhere from a few seconds to 15 minutes. Incremental builds were notably slow when modifying enums and extensions. Now that WMO is on across all of our modules, we're seeing clean builds of about 6 minutes, and incremental builds of ~4 minutes and under. I know this is an older posting, but I'm wondering if anyone can shed some light on this?
|
# ? Oct 18, 2016 00:22 |
|
dc3k posted:Coworker brought up this posting today: https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20160307/001384.html This is just a guess but when you aren't doing WMO each file gets a separate invocation of the compiler like traditional C code so there may be a lot of duplicate work going on. WMO is probably taking advantage of keeping the ASTs, type resolution caches, etc in the same process. rjmccall would know more.
|
# ? Oct 18, 2016 05:44 |
|
That is probably what is happening, yes. Or somehow it's contributing to there just not being nearly as much code to actually emit in the end. Modifying types is one of those things that does require a bunch of downstream code to be recompiled, at least under our current compilation strategy. At least some of that work is known to be unnecessary, and we're hoping to put a lot of effort into fixing that this year — basically, this is going to be a long year of technical retrenchment across a lot of fronts, and we think it'll pay some pretty serious dividends across the board.
|
# ? Oct 18, 2016 06:01 |
|
Thanks for the responses. Passing this along to the team that's working on our compile times.
|
# ? Oct 18, 2016 20:14 |
|
I strongly suggest the Server APIs (https://swift.org/server-apis/) people not implement HTTP and WebSockets in a one-off way, and take the approach of netty or Wangle. Facebook uses Wangle, which is basically a C++ version of Netty. Netty is a Java framework which is an extremely effective and lean networking framework in use by many companies, even hedge funds (where latency and performance is paramount). Twitter also uses (or used, I don't know what they're doing at this point) Netty via Finagle, a Scala layer on top. Netty's biggest advantage besides performance is that it is very composable, so it's also useful for many different kinds of daemons or API gateways. Jersey is also another potentially interesting thing to look at for creating servers, but given that it leverages a lot of Java features it might not be as relevant.
|
# ? Oct 26, 2016 07:26 |
|
If you want to discuss that here, that's cool, but it sounds more like you're asking someone to relay your thoughts, and as far as I know nobody listening here is a contributor. If you're interested in contributing, even just to say exactly that and drop the mike, this is an excellent opportunity to join up and make a difference.
|
# ? Oct 26, 2016 16:35 |
|
Okay. Random interjections and dropping he mic is what I do best!
|
# ? Oct 26, 2016 17:38 |
|
|
# ? May 30, 2024 10:09 |
|
Doctor w-rw-rw- posted:Okay. Random interjections and dropping he mic is what I do best! Godspeed!
|
# ? Oct 26, 2016 18:16 |