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

«‹›48 »

Flobbster: Feb 17, 2005; "Cadet Kirk, after the way you cheated on the Kobayashi Maru test I oughta punch you in tha face!"

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!" :bang:

# ? Sep 21, 2016 14:14

Adbot: ADBOT LOVES YOU

# ? May 30, 2024 06:02

sarehu: Apr 20, 2007; (call/cc call/cc)

Avoiding mistakes and avoiding the need to implement stupid unit tests sounds like a great idea to me.

# ? Sep 21, 2016 18:39

Vesi: Jan 12, 2005; pikachu looking at?

I don't see the point since override exists already

# ? Sep 21, 2016 19:51

Flobbster: Feb 17, 2005; "Cadet Kirk, after the way you cheated on the Kobayashi Maru test I oughta punch you in tha face!"

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

sarehu: Apr 20, 2007; (call/cc call/cc)

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

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

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

Simulated: Sep 28, 2001; Lowtax giveth, and Lowtax taketh away.; College Slice

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

toiletbrush: May 17, 2010

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

brap: Aug 23, 2004; Grimey Drawer

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

TheReverend: Jun 21, 2005

_{_{sorry wrong thread}}

TheReverend fucked around with this message at 22:54 on Sep 23, 2016

# ? Sep 23, 2016 22:49

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

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

Kallikrates: Jul 7, 2002; Pro Lurker

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

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

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

dc3k: Feb 18, 2003; what.

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. :confused:

dc3k fucked around with this message at 18:22 on Sep 28, 2016

# ? Sep 28, 2016 18:19

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

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.

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.

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

dc3k: Feb 18, 2003; what.

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:

 switch type {
 case .CaseA(_, let b?, _):
   return something
 case .CaseB(_, let b?):
   return something
 case .CaseC(_, let b?):
   return something
 }

and the enum definition:

code:

 enum Type {
  case CaseA(a: String?, b: Foo?, c: Bar?)
  case CaseB(a: String?, b: Baz?)
  case CaseC(a: String?, b: FooBar?)
}

# ? Sep 28, 2016 19:00

Kallikrates: Jul 7, 2002; Pro Lurker

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

Toady: Jan 12, 2009

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.
code:
 switch type {
 case .CaseA(_, let b?, _):
   return something
 case .CaseB(_, let b?):
   return something
 case .CaseC(_, let b?):
   return something
 }
and the enum definition:
code:
 enum Type {
  case CaseA(a: String?, b: Foo?, c: Bar?)
  case CaseB(a: String?, b: Baz?)
  case CaseC(a: String?, b: FooBar?)
}

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

dc3k: Feb 18, 2003; what.

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 :v:

# ? Sep 28, 2016 20:48

Toady: Jan 12, 2009

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

thegasman2000: Feb 12, 2005; Update my TFLC log? BOLLOCKS!
/

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:

	@IBOutlet weak var iMage: UIImageView!


	iMage.image = UIImage(named : "randomPic.jpg")
        iMage.layer.cornerRadius = iMage.frame.size.width/2
        iMage.clipsToBounds = true

So when I run this I get no image at all.. When I comment out the cornerRadius line it runs fine and I get a square image. ?

# ? Sep 28, 2016 22:54

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

thegasman2000 posted:

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:
	@IBOutlet weak var iMage: UIImageView!


	iMage.image = UIImage(named : "randomPic.jpg")
        iMage.layer.cornerRadius = iMage.frame.size.width/2
        iMage.clipsToBounds = true
So when I run this I get no image at all.. When I comment out the cornerRadius line it runs fine and I get a square image. ?

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

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

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.

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.

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

thegasman2000: Feb 12, 2005; Update my TFLC log? BOLLOCKS!
/

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

leftist heap: Feb 28, 2013; Fun Shoe

Is there something in the symantics around protocols/extensions that I'm missing here:

code:

protocol Events {
    associatedtype EventType: Hashable
    associatedtype EventPayload
    typealias HandlerType = (EventPayload) -> Void
    
    var eventListeners: [EventType: Array<HandlerType>] { get set }
    
}

public enum TimerEventType {
    case TIMER_START
}

public class TimerEvents: Events {
    internal var eventListeners = [TimerEventType : Array<(TimerContext)->Void>]()
    typealias EventType = TimerEventType
    typealias EventPayload = TimerContext
    
    public func subscribe(eventType: TimerEventType, handler: @escaping (TimerContext) -> Void) {
        var handlersForType = eventListeners[eventType] ?? []
        handlersForType.append(handler)
        eventListeners.updateValue(handlersForType, forKey: eventType)
    }
}

extension Events {
    public mutating func subscribe(eventType: EventType, handler: @escaping HandlerType) {
        var handlersForType = eventListeners[eventType] ?? []
        handlersForType?.append(handler)
        if handlersForType != nil {
            eventListeners.updateValue(handlersForType!, forKey: eventType)
        }
    }
}

Why is it in the extension handlersForType is still optional even after using ??, but not in the concrete implementation? Maybe I missed something in the docs for extensions and protocols.

# ? Sep 29, 2016 18:59

Kallikrates: Jul 7, 2002; Pro Lurker

Looks some weirdness in the order of operations or type constraints.

code:

extension Events {
  public mutating func subscribe(eventType: EventType, handler: @escaping HandlerType) {
    var handlersForType: [HandlerType] = eventListeners[eventType] ?? []
    handlersForType.append(handler)
    eventListeners.updateValue(handlersForType, forKey: eventType)
  }
}

works for me.

# ? Sep 29, 2016 19:13

leftist heap: Feb 28, 2013; Fun Shoe

Kallikrates posted:

Looks some weirdness in the order of operations or type constraints.

code:

extension Events {
  public mutating func subscribe(eventType: EventType, handler: @escaping HandlerType) {
    var handlersForType: [HandlerType] = eventListeners[eventType] ?? []
    handlersForType.append(handler)
    eventListeners.updateValue(handlersForType, forKey: eventType)
  }
}

works for me.

Weird.

# ? Sep 29, 2016 19:32

Doctor w-rw-rw-: Jun 24, 2008

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

Flobbster: Feb 17, 2005; "Cadet Kirk, after the way you cheated on the Kobayashi Maru test I oughta punch you in tha face!"

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

Doctor w-rw-rw-: Jun 24, 2008

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

thegasman2000: Feb 12, 2005; Update my TFLC log? BOLLOCKS!
/

code:


//Save Image
        _ = ppImagePicked.image
        let imageData = UIImageJPEGRepresentation(PPimagePicked.image!, 0.6)
        let compressedJPGImage = UIImage(data: imageData!)
        UIImageWriteToSavedPhotosAlbum(compressedJPGImage!, nil, nil, nil)
        // Get Document Root Path
        let path = URL(fileURLWithPath: NSHomeDirectory()).appendingPathComponent("Documents/profile.jpg")
        do {
        //Save image to Root
                try imageData?.write(to: path, options:  .atomic)
            print("Saved To Root")
            } catch let error {
                print(error)
            }

Crossposting from the IOS thread... This is giving me an error "[Generic] Creating an image format with an unknown type is an error" but none of the reading I have found around that has helped me any. Its just an image picked and stored in the directory for use as a profile image, it really should be this hard surely!

thegasman2000 fucked around with this message at 20:03 on Oct 6, 2016

# ? Oct 3, 2016 10:12

Doctor w-rw-rw-: Jun 24, 2008

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

dc3k: Feb 18, 2003; what.

Coworker brought up this posting today: https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20160307/001384.html

quote:

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

Simulated: Sep 28, 2001; Lowtax giveth, and Lowtax taketh away.; College Slice

dc3k posted:

Coworker brought up this posting today: https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20160307/001384.html

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?

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

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

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

dc3k: Feb 18, 2003; what.

Thanks for the responses. Passing this along to the team that's working on our compile times.

# ? Oct 18, 2016 20:14

Doctor w-rw-rw-: Jun 24, 2008

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

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

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

Doctor w-rw-rw-: Jun 24, 2008

Okay. Random interjections and dropping he mic is what I do best!

# ? Oct 26, 2016 17:38

Adbot: ADBOT LOVES YOU

# ? May 30, 2024 06:02

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

Doctor w-rw-rw- posted:

Okay. Random interjections and dropping he mic is what I do best!

Godspeed!

# ? Oct 26, 2016 18:16

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

«‹›48 »