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 »

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

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

Adbot: ADBOT LOVES YOU

# ? May 13, 2024 21:47

lord funk: Feb 16, 2004

me: UIColor *color = [uic
Xcode: I know! UICollectionElementKindSectionFooter!
me: :stare:

# ? Apr 3, 2015 21:04

Kallikrates: Jul 7, 2002; Pro Lurker

me 99% of the time:

me: tr
Xcode: ...
me: tru
Xcode: ...
me: true
Xcode: ...

# ? Apr 3, 2015 23:05

brap: Aug 23, 2004; Grimey Drawer

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

Kallikrates: Jul 7, 2002; Pro Lurker

More like no autocomplete showing/working at all.

# ? Apr 4, 2015 16:28

Doh004: Apr 22, 2007; Mmmmm Donuts...

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

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

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

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

This code causes swiftc to crash with no error message:

code:

    override var transitioningDelegate: UIViewControllerTransitioningDelegate? {
        get {
            if !UIDevice.isPad && super.transitioningDelegate == nil {
                super.transitioningDelegate = ActionSheetPresentationManager()
            }
            return super.transitioningDelegate
        }
        set {
            super.transitioningDelegate = newValue
        }
    }

This code compiles just fine:

code:

    override var transitioningDelegate: UIViewControllerTransitioningDelegate? {
        get {
            if super.transitioningDelegate == nil && !UIDevice.isPad {
                super.transitioningDelegate = ActionSheetPresentationManager()
            }
            return super.transitioningDelegate
        }
        set {
            super.transitioningDelegate = newValue
        }
    }

I refactored this anyway to set up the transition elsewhere, but I just found it curious.

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

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

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

Doh004: Apr 22, 2007; Mmmmm Donuts...

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

Kallikrates: Jul 7, 2002; Pro Lurker

Xcode webpage says 6.3 is about to land in the app store today.

# ? Apr 8, 2015 18:41

Toady: Jan 12, 2009

I wonder what, if anything, changed from the most recent beta.

# ? Apr 8, 2015 22:32

brap: Aug 23, 2004; Grimey Drawer

Just got xcode 6.3 and :pwn:

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

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

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

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

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

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

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

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

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

brap: Aug 23, 2004; Grimey Drawer

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

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

Am I stupid for thinking this should work?

code:

//bad example code removed

Also did I miss a built-in function somewhere for concatenating sequences?

Simulated fucked around with this message at 18:21 on Apr 10, 2015

# ? Apr 10, 2015 01:05

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

+ ?

# ? Apr 10, 2015 01:24

dizzywhip: Dec 23, 2005

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:

public class StandardViewController: NSViewController {
	override public init() {
		super.init()
	}
	
	public convenience init(view: NSView) {
		self.init()
		self.view = view
	}
	
	override private init?(nibName: String?, bundle: NSBundle?) {
		super.init(nibName: nibName, bundle: bundle)
	}
	
	required public init(coder: NSCoder) {
		fatalError("NSCoding not supported.")
	}
}

I can't recall the exact reason for the need of the third private override -- I think adding it prevented a crash I was getting in a previous beta. The important one was the designated init(). In the latest Xcode, that initializer now produces an "Initializer does not override a designated initializer from its superclass" error, which makes sense -- init() isn't a valid initializer for NSViewController, let alone a designated one. Presumably, it was working before because it was finding and overriding NSObject's init(), but I understand that you're only supposed to override initializers from the immediate superclass.

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:

public class StandardViewController: NSViewController {
	public init() {
		super.init!(nibName: nil, bundle: nil)
	}
}

Where my initializer would cause a runtime error if the superclass initializer actually did fail. I tried doing this:

code:

public class StandardViewController: NSViewController {
	public init!() {
		super.init(nibName: nil, bundle: nil)
	}
}

But that fails with the error "Failable initializer 'init()' cannot override a non-failable initializer". I assume it's conflicting with NSObject's init(), which would be a bug, right?

# ? Apr 10, 2015 05:34

jawbroken: Aug 13, 2007; messmate king

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?

Advance to the next element and return it, or nil if no next element exists.

Requires: next() has not been applied to a copy of self since the copy was made, and no preceding call to self.next() has returned nil. Specific implementations of this protocol are encouraged to respond to violations of this requirement by calling preconditionFailure("...").

# ? Apr 10, 2015 12:05

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

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:

func tiddlyWinks<S : SequenceType>(lhs:S, rhs:S)
    -> SequenceOf<S.Generator.Element> {
        return SequenceOf({
            return GeneratorOf({
                return nil
            })
        })
}

extension Array {
    func tiddlyWinks<S : SequenceType where S.Generator.Element == T>(rhs:S) -> SequenceOf<S.Generator.Element> {
        return tiddlyWinks(self, rhs) //ERROR: Will not compile
    }
}

let i = [5,6,7]
let x = [9,1]
tiddlyWinks(i, x)

Even simplifying it down further the error makes no sense. i and x are Arrays, they clearly satisfy the constraint, therefore Array<T> should satisfy it as well. Why does the extension fail to compile?

Simulated fucked around with this message at 18:22 on Apr 10, 2015

# ? Apr 10, 2015 18:05

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

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

Swift code:

  func tiddlyWinks<S : SequenceType, T : SequenceType where S.Generator.Element == T.Generator.Element>(lhs:S, rhs:T)

Your only other problem is that, within the Array extension, tiddlyWinks shadows the global declaration, and you will need to refer to the global as TheEnclosingModuleName.tiddlyWinks.

# ? Apr 10, 2015 19:30

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

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

King of Gulps: Sep 4, 2003

fleshweasel posted:

Just got xcode 6.3 and

I had some SJW <BS> in mine

# ? Apr 10, 2015 23:02

Axiem: Oct 19, 2005; I want to leave my mind blank, but I'm terrified of what will happen if I do

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:

typealias TypeA = Int
typealias TypeB = Int
let x = TypeA(1)
let y = TypeB(2)
let z = x + y // <-- I want an error or warning on this line

Doing it without necessarily using a typealias would be okay, but I'm not sure what other options are out there.

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:

func add(x: Int)(y: Int) -> Int {
    return x + y
}
let add2 = add(2)

Is there any way to query add2 to get the value of x = 2? Especially because if instead of 2, it was a value computed somewhere else.

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

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

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
Swift code:
  func tiddlyWinks<S : SequenceType, T : SequenceType where S.Generator.Element == T.Generator.Element>(lhs:S, rhs:T)
Your only other problem is that, within the Array extension, tiddlyWinks shadows the global declaration, and you will need to refer to the global as TheEnclosingModuleName.tiddlyWinks.

The original version did use two separate types but the shadowing makes sense.

# ? Apr 11, 2015 03:15

brap: Aug 23, 2004; Grimey Drawer

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

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

You still need final even with virtual, so it's not really an "instead" thing.

# ? Apr 11, 2015 21:50

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

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

Doh004: Apr 22, 2007; Mmmmm Donuts...

King of Gulps posted:

I had some SJW <BS> in mine

This was pretty funny :respek:

# ? Apr 13, 2015 14:26

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

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

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

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

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

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

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:

(lldb) po self
error: <EXPR>:1:1: error: use of unresolved identifier 'self'
self
^
(lldb)

This is a 100% swift project. The variables window in Xcode sees self just fine but the lldb window refuses (along with refusing any form of autocomplete). I've done a full clean, nuked derived data, nuked my lldbinit just in case, etc.

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

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

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

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

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

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

We're looking into a major generalization of that syntax, actually.

# ? Apr 20, 2015 23:12

lord funk: Feb 16, 2004

Hey congrats on being the 'most loved' language on the Stack Overflow survey.

# ? Apr 20, 2015 23:17

Adbot: ADBOT LOVES YOU

# ? May 13, 2024 21:47

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

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

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

«‹›48 »