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 »

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

I don't know, that seems like it should work. Did you try defining typealias EdibleFood = F explicitly? That shouldn't be necessary, but I know that our logic for inferring those associated types has some bugs in it, basically because it's trying too hard to do everything at once.

# ? Jan 4, 2015 10:02

Adbot: ADBOT LOVES YOU

# ? May 14, 2024 05:32

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

rjmccall posted:

I don't know, that seems like it should work. Did you try defining typealias EdibleFood = F explicitly? That shouldn't be necessary, but I know that our logic for inferring those associated types has some bugs in it, basically because it's trying too hard to do everything at once.

Doesn't appear to work. Created rdar://19371678

# ? Jan 5, 2015 07:12

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

I realized again why trailing closure syntax is not necessarily a good idea even if it is a cute trick. I also realized why I dislike the property declaration syntax. All the syntax blocks look the same. A property getter block look the same as a function "get" called with trailing closure syntax.

It came up during a code review where I had to explain to team members who are getting used to Swift what it all was. (Funny enough, trailing closure syntax worked as intended because they didn't realize my lock function wasn't a built-in Swift lock operator.) I had to explain all the syntax differences around what a trailing closure is, how properties are declared, when Swift decides to automatically create a backing field and when it doesn't, etc.

I now believe making closures look like regular syntactical blocks was a mistake that will annoy everyone for years to come.

Properties should have just used an explicit property keyword instead of var.

That's it, just wanted to complain a bit. Back to your regularly scheduled program.

# ? Jan 20, 2015 00:23

dizzywhip: Dec 23, 2005

I mean, it should be expected that you'll have to explain how things work if you're showing code to developers who are still learning the language. I like the simplicity of sharing syntax between variable and property declarations -- adding an extra keyword seems unnecessary. You'd have to be pretty drastically unaware of your context if you're not sure if something is a variable or a property.

I don't have strong feelings about trailing closure syntax one way or the other, but you don't have to use it if you think it's confusing. None of this stuff should be hard to learn and get used to though, so I don't see any of it being a long-term hurdle.

# ? Jan 20, 2015 00:53

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

It's all learnable and I work with some seriously smart people; I'm not worried about that. It's a new language; splurge a little on the keywords, OK? Actual users of programming languages care far, far less about reserved keywords than language designers think they care.

# ? Jan 20, 2015 01:32

brap: Aug 23, 2004; Grimey Drawer

Some languages (C#) are guilty of requiring too many keywords-- just my opinion. Although in this case it's a lot like C#, where you declare the property like a field up until you open the braces and define the getter and setter with keywords.

When does swift automatically create a getter, setter and backing field? I've only explicitly assigned or retrieved the value of a field with the property syntax.

I think I agree on the trailing closure syntax. I probably won't use it in my personal style any more. It is more clear to a newbie to have the trailing parentheses that the function invocation isn't over; this thing inside the braces is an argument to the function.

# ? Jan 20, 2015 01:38

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

Ender.uNF posted:

It's all learnable and I work with some seriously smart people; I'm not worried about that. It's a new language; splurge a little on the keywords, OK? Actual users of programming languages care far, far less about reserved keywords than language designers think they care.

That's great, but I'm not sure why you think the decision was dictated by not wanting to use a keyword. It wasn't, not even slightly. We've been pretty aggressive about stealing things as keywords if we thought it was necessary and helped.

The anonymous function syntax was guided by (1) not wanting them to feel syntactically heavyweight, especially in the very common case of a short function with no arguments, and (2) specifically wanting people to be able to make APIs with trailing closure syntax that felt like built-in language features.

Using var for all kinds of property was also intentional. What are you suggesting, that "var" be used for stored properties and "property" be used for computed properties? Because that would be a total disaster. It doesn't align with how people actually use the word "property", or with the existing meaning of @property in Objective-C, so instead of telling your coworkers a pretty straightforward rule about how having explicit accessors suppresses storage, you'd be ranting for ten minutes about all the different definitions of "property" and how we got it completely wrong in Swift.

Really, unless you're telling us to use more Algol-like begin/end block directives instead of curly braces, I have no idea what you think would be fixed by hitting things with the keyword stick.

# ? Jan 20, 2015 01:53

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

I tend to agree that you should not be using trailing closure syntax on every single call that takes a function. I'd say it's best reserved for things that feel like statements.

# ? Jan 20, 2015 01:57

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

My general rule of thumb is that if it would be reasonable, sensible and possible to chain another method call after the method taking a closure, it shouldn't use the trailing closure syntax even if there happens not to be another call after it; otherwise it probably should. This is slightly more broad than statementy things.

# ? Jan 20, 2015 05:07

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

fleshweasel posted:

Some languages (C#) are guilty of requiring too many keywords-- just my opinion. Although in this case it's a lot like C#, where you declare the property like a field up until you open the braces and define the getter and setter with keywords.

Fair point and I wasn't arguing against the enclosed getter/setter, just that for a quick visual scan of the code it would be nice if properties had a separate keyword because the getter/setter blocks are indistinguishable from a trailing closure (again, during a quick scan).

quote:

When does swift automatically create a getter, setter and backing field? I've only explicitly assigned or retrieved the value of a field with the property syntax.

Well it basically creates a backing field when you don't specify a getter/setter, otherwise you're responsible for creating it. That's a departure from Obj-C but not a big deal. You can use willSet/didSet to observe changes without messing with the storage. When I want to manually manage storage I just create a private var with a leading underscore so it works effectively like Obj-C. Lazy properties also cover a common case for having custom getters anyway.

rjmccall posted:

That's great, but I'm not sure why you think the decision was dictated by not wanting to use a keyword. It wasn't, not even slightly. We've been pretty aggressive about stealing things as keywords if we thought it was necessary and helped.

I do recall there being an argument about why some things in the first few betas were attributes instead of keywords and someone from the Apple side brought up avoiding the introduction of new keywords. I didn't mean to imply that was the reason in this case though!

quote:

The anonymous function syntax was guided by (1) not wanting them to feel syntactically heavyweight, especially in the very common case of a short function with no arguments, and (2) specifically wanting people to be able to make APIs with trailing closure syntax that felt like built-in language features.

I think you and I discussed the cuteness of trailing closures after Swift was announced and we both came down negatively toward it, but I understand why it's designed that way and I use it myself so I guess I'm a hypocrite. It is handy for something like lock() and I just can't stop myself.

My dislike of the explicitly-specified parameters closure syntax is purely aesthetic and my own personal opinion. I may be in the minority there, but I would have preferred a syntax that kept the parameters and return type outside the body of the closure so it more closely aligned with how functions are declared. Again, not a huge issue.

quote:

Using var for all kinds of property was also intentional. What are you suggesting, that "var" be used for stored properties and "property" be used for computed properties? Because that would be a total disaster. It doesn't align with how people actually use the word "property", or with the existing meaning of @property in Objective-C, so instead of telling your coworkers a pretty straightforward rule about how having explicit accessors suppresses storage, you'd be ranting for ten minutes about all the different definitions of "property" and how we got it completely wrong in Swift.

Really, unless you're telling us to use more Algol-like begin/end block directives instead of curly braces, I have no idea what you think would be fixed by hitting things with the keyword stick.

I was suggesting that stored and computed properties be declared with "property" so they stand out more during a quick visual code scan as opposed to using the same syntax as local declarations. You might be right in one aspect though - maybe if it did work that way I'd hate it. I can appreciate the symmetry of having global, class/struct, and locals all declared the same way.

# ? Jan 20, 2015 08:56

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

Ender.uNF posted:

I do recall there being an argument about why some things in the first few betas were attributes instead of keywords and someone from the Apple side brought up avoiding the introduction of new keywords. I didn't mean to imply that was the reason in this case though!

Ah, sure. Attributes are a bit different, for a couple of reasons. The biggest is that they're an unbounded set � for one, we'll probably keep adding builtin attributes forever, but we also want to allow user-defined attributes at some point. Fine, whatever, maybe we can get away with forcing you to change variable names when you upgrade compilers, but it would be awful if you had to deal with that with every third-party library you use, too.

Mostly we settled that by (1) making a (hopefully) clearer policy about what's spelled with @ and what isn't and (2) deciding that we were comfortable embracing context-sensitive parsing for the things we weren't spelling with @.

Ender.uNF posted:

I think you and I discussed the cuteness of trailing closures after Swift was announced and we both came down negatively toward it, but I understand why it's designed that way and I use it myself so I guess I'm a hypocrite. It is handy for something like lock() and I just can't stop myself.

I really think it's fine for top-level functions like lock. I'm ambivalent about anything more complex. There are people who go overboard with it, but I'm not sure there's a way for the compiler to draw that line well.

Ender.uNF posted:

My dislike of the explicitly-specified parameters closure syntax is purely aesthetic and my own personal opinion. I may be in the minority there, but I would have preferred a syntax that kept the parameters and return type outside the body of the closure so it more closely aligned with how functions are declared. Again, not a huge issue.

That would also have been my preference. The problem is that we all liked the the bare-braces syntax as the simplest extreme, but you kindof want the syntax to "grow" cleanly as it becomes more explicit, and the team felt that (1) it was weird for the syntax to suddenly acquire a prefix and (2) it wasn't clear how to fit stuff like capture lists into that. So we ended up with this, at least so far.

Ender.uNF posted:

I was suggesting that stored and computed properties be declared with "property" so they stand out more during a quick visual code scan as opposed to using the same syntax as local declarations. You might be right in one aspect though - maybe if it did work that way I'd hate it. I can appreciate the symmetry of having global, class/struct, and locals all declared the same way.

Oh, so you'd basically have property inside types and var elsewhere? Yeah, that's much more reasonable than dividing by stored/computed. It is something we considered. It's a fairly complex topic because it doesn't quite stand alone; there are several other related decisions which we've collectively talked to death.

I dunno. I'm not sure I believe that it's difficult to tell the difference between type-scope declarations and method bodies at a glance. Maybe in theory, but in practice, no, and especially not if you've organized or commented your code at all.

# ? Jan 20, 2015 10:29

ultramiraculous: Nov 12, 2003; "No..."; Grimey Drawer

Random benchmark-y question, but is there a reason that the array of optionals in this case would consistently sort more quickly:

code:

class Number {
  var value: Int
  init(_ value: Int) {
    self.value = value
  }
}

let collectionOpt: [Number?] = (0..<10000).map( { _ in Number(Int(arc4random_uniform(1 << 20))) })
let collection: [Number] = (0..<10000).map( { _ in Number(Int(arc4random_uniform(1 << 20))) })

func perfMeasure(label: String, work: () -> ()) {
  var startTime = NSDate.timeIntervalSinceReferenceDate()
  for _ in 0..<100 {
    work()
  }
  NSLog("\(label): [%.03f ms]" , (NSDate.timeIntervalSinceReferenceDate() - startTime) * 1000 )
}

func testArray() {
  perfMeasure("testArray") {
    var a = Array<Number>(collection)
    a.sort({$0.value < $1.value})
  }
}

func testContiguousArray() {
  perfMeasure("testContArray") {
    var a = ContiguousArray<Number>(collection)
    a.sort({$0.value < $1.value})
  }
}

func testArrayWithOptionals() {
  perfMeasure("testArrayWithOptionals") {
    var a = Array<Number?>(collectionOpt)
    a.sort({$0!.value < $1!.value})
  }
}


testArray()
testContiguousArray()
testArrayWithOptionals()

Changing Number to a struct makes the [Number?] array perform slower, which seems like what you'd expect. I'm assuming it's something specific to arrays of references.

# ? Jan 23, 2015 10:02

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

An optional class type can still be represented with a single pointer; an optional Int needs an extra bit of storage, which in an array context means each element will take twice the size. So that should help the class case.

Copying a class reference around normally requires refcounting, which would be slower � but, of course, swapping them doesn't need to copy, just move. So that shouldn't matter.

I would expect actually doing the comparisons to be significantly slower with the class objects, though, since there's an extra indirection and a lot of poor cache locality.

Oh, if sort isn't actually being specialized for some reason, copying the optional int might require an extra indirect call per copy. That would suck. This is with optimization enabled, right?

rjmccall fucked around with this message at 10:55 on Jan 23, 2015

# ? Jan 23, 2015 10:51

ultramiraculous: Nov 12, 2003; "No..."; Grimey Drawer

Yeah, this is with -O. The numbers actually come out "right" with -ONone, but it also takes 10x longer :-P

So this is a pretty representative result from an rMBP:

code:

Class:
testArray: [855.361 ms]
testArrayWithOptionals: [711.702 ms]

Stuct:
testArray: [113.779 ms]
testArrayWithOptionals: [168.950 ms]

Basically the Struct version behaves like you'd expect, where the optionals are slightly slower, presumably because of the optionality bit needing to get read/checked for each comparison.

The class version of [Number] consistently coming in slower than the [Number?] one is baffling a few people.

# ? Jan 23, 2015 19:39

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

ultramiraculous posted:

Basically the Struct version behaves like you'd expect, where the optionals are slightly slower, presumably because of the optionality bit needing to get read/checked for each comparison.

That and the array is twice as long (in bytes).

ultramiraculous posted:

The class version of [Number] consistently coming in slower than the [Number?] one is baffling a few people.

Oh, I see what you're saying. Yes, that is bizarre.

Oh, I know what that is. [Number] is allowed to be bridged to NSArray; [NSNumber?] isn't, and at -O we can eliminate those checks. ContiguousArray is faster for this reason.

# ? Jan 23, 2015 22:12

brap: Aug 23, 2004; Grimey Drawer

So I have an objective-C app with a custom Swift framework embedded, and I'm suddenly getting error warnings out the wazoo in reference to my Swift framework. It succeeds when I build and the errors vanish for just a moment before reappearing. Any ideas? I had just changed my framework's project setting to be OS X SDK, and changed it back to iOS SDK when I had problems.

# ? Jan 24, 2015 19:43

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

Are you seeing the errors in the objective-c code that references the swift code in its bridging header file?

# ? Jan 24, 2015 23:11

brap: Aug 23, 2004; Grimey Drawer

Do you mean the ProductName-Swift.h that gets generated? I don't include that directly because I'm including the whole framework. The errors only reference my view controller code (from what I've seen), complaining that it doesn't know what that type is that I defined in Swift.

# ? Jan 24, 2015 23:29

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

Yeah, that's what I'd meant. But yeah, I had a lot of trouble with fake errors that went away when building that were "fixed" when I included it in each file I wanted to use it. :iiam:

# ? Jan 24, 2015 23:32

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

If you can isolate anything about the failure, please consider filing a bug. These sorts of bugs are often specific to the exact details of your project, and we can't exhaustively test everything internally.

# ? Jan 25, 2015 04:13

MrSaturn: Sep 8, 2004; Go ahead, laugh. They all laugh at first...

I've got a couple questions - for background, I'm building a Universal app whose use case will primarily be iPad, but I'd like some flexibility to let people on smaller devices use the app in a pinch. Most of the screens in my app will be served up with a splitviewcontroller, having a lefthand sidebar and a main content area.

Question 1: One of the things I'll need in my app is global access to the bluetooth stack. I've got a bluetooth manager class set up that talks to BT devices like one would expect, but right now I'm not sure what the best practice is for when and where to load it. Is it the sort of thing I can fire up in AppDelegate? Should I instead instantiate it in my root viewcontroller of the splitview?

Question 2: Are there patterns and practices that I should be using for navigating from screen to screen? Right now I've got what feels like a mess of Segues on a storyboard, which each have an ID that is referenced along these lines:

code:

override func prepareForSegue(segue: UIStoryboardSegue, sender: AnyObject?) {
    if (segue.identifier? == "seguenameHere" )
    {
      self.storyboard?.instantiateViewControllerWithIdentifier
           ("ViewControllerIDFromStoryboardGoesHere") 
           as SpecificViewControllerClassNameHere
    }

}

Having strings all over my code feels messy, and this logic feels messier still to be scattered across viewcontrollers all over the place. Worse still, sometimes I'll need to change what's in both my left and right viewcontroller of the split view based on user input, and I'm not sure the best way to do that. I have experiemented a bit with using structs to store Segue names for each ViewController, but I'm not convinced that's best either.

Any tips are appreciated, or tutorials to look at. This is my first swift app, and it is rather ambitious. My background is writing Windows 8 apps, so I'm in a whole new world.

# ? Jan 28, 2015 03:07

Kallikrates: Jul 7, 2002; Pro Lurker

1. App delegate might be smart since you have quick access to app state (might not want to start bluetooth under certain app states) but anywhere early is fine. So long as your manager/service/store is available when you need it. You might even lazy load it as needed. It mostly depends on your requirements for the object.

2. No help other than to say that Strings to reference storyboard segues (and other Interface Builder identifiers) is something that annoys me to no end. Declaring a constant is better but you still have to mirror it in interfacebuilder so that copy paste errors can happen (or a developer forgets a step)

# ? Jan 28, 2015 04:16

brap: Aug 23, 2004; Grimey Drawer

What triggers the transitions between views? Simple stuff like hitting a button or selecting a table view cell should be defined in the storyboard.

# ? Jan 28, 2015 05:53

MrSaturn: Sep 8, 2004; Go ahead, laugh. They all laugh at first...

Those are exactly the two types of transitions I've got at the moment - but how should I be handling an action that should change both views? The case in particular I'm talking about is akin to this:

To start, the left is a table viewcontroller contains a list of classes (like for a school... classroom type classes), and the right container contains some read-only information

Clicking on the add button (or an existing class in the table) should then transition to a list of people who are attending the class on the left, and some metadata about the class on the right, and thus both viewcontrollers need to segue.

Creating a segue on the storyboard only points to one thing, not two. Unless my segue should point to the splitview instead? This is all very confusing

# ? Jan 28, 2015 06:33

Kallikrates: Jul 7, 2002; Pro Lurker

So I've seen/read that access control has performance implications. Marking things final allows more optimizations than internal or public but I haven't been able to get good data about private. My intuition is that private could be faster than final. Anyone found any guidance?

https://mikeash.com/pyblog/friday-qa-2014-07-04-secrets-of-swifts-speed.html

# ? Jan 30, 2015 16:39

Kallikrates: Jul 7, 2002; Pro Lurker

Kallikrates posted:

So I've seen/read that access control has performance implications. Marking things final allows more optimizations than internal or public but I haven't been able to get good data about private. My intuition is that private could be faster than final. Anyone found any guidance?

https://mikeash.com/pyblog/friday-qa-2014-07-04-secrets-of-swifts-speed.html

Answering my own question with a quote:

quote:

2:23 PM <Kallikrates> I've found a couple sources and examples stating that declaring things final with access control has beneficial effects re compiler optimization My intuition would be to say something similar with private but I cant find stuff to back that up.
2:24 PM <mikeash> why would private do it?
2:27 PM <Kallikrates> sec googling the right word to use...
2:28 PM <Kallikrates> the compiler can make similar assumptions about overriding?
2:29 PM <mikeash> you could still subclass and override it if you do it in the same file, although I suppose the compiler could easily see you don't do that and then optimize accordingly
2:29 PM <Kallikrates> even if you use a same named function, name mangling will produce different symbols
2:29 PM <Kallikrates> oh, I handnt considered a same file subclass
2:29 PM <Kallikrates> silly developers
2:30 PM <mikeash> it's the only language I know of where "private" allows that

# ? Jan 30, 2015 20:32

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

But we do, in fact, detect that and optimize based on it.

The long-term plan is that we'll be able to do a similar analysis to your entire project, so we'd similarly be able to devirtualize anything not public/dynamic.

# ? Jan 30, 2015 22:23

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

rjmccall posted:

But we do, in fact, detect that and optimize based on it.

The long-term plan is that we'll be able to do a similar analysis to your entire project, so we'd similarly be able to devirtualize anything not public/dynamic.

Are tail calls optimized currently? Someone was telling me Swift does sometimes optimize tail calls but there's no way to guarantee that.

# ? Jan 30, 2015 22:41

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

Swift can't guarantee tail calls for similar reasons to C++: sometimes we need to clean things up after a call. We have an easier time than C++, because Swift is generally allowed to reorder destructors, but if the value being cleaned up is needed by the final call, there's not much we can do.

If Swift doesn't need to do anything after the final call, LLVM will try to perform TCO as a best-effort thing.

# ? Jan 30, 2015 22:58

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

Ender.uNF posted:

Are tail calls optimized currently?

I'm curious because people often want this: Why do you care? Is it performance? Do you want to write code that relies on tail recursion?

# ? Jan 30, 2015 22:59

ulmont: Sep 15, 2010; IF I EVER MISS VOTING IN AN ELECTION (EVEN AMERICAN IDOL) ,OR HAVE UNPAID PARKING TICKETS, PLEASE TAKE AWAY MY FRANCHISE

sarehu posted:

I'm curious because people often want this: Why do you care? Is it performance? Do you want to write code that relies on tail recursion?

Not performance, but safety. The way I was taught functional programming a million years ago explicitly depends on tail recursion to avoid stack overflows where otherwise you'd have to use loops.

# ? Jan 30, 2015 23:10

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

sarehu posted:

I'm curious because people often want this: Why do you care? Is it performance? Do you want to write code that relies on tail recursion?

I was just curious. I've never felt limited by it and if an issue arises I refactor to use iteration or use a manually-managed stack data structure allocated on the heap.

rjmccall posted:

Swift can't guarantee tail calls for similar reasons to C++: sometimes we need to clean things up after a call. We have an easier time than C++, because Swift is generally allowed to reorder destructors, but if the value being cleaned up is needed by the final call, there's not much we can do.

If Swift doesn't need to do anything after the final call, LLVM will try to perform TCO as a best-effort thing.

If the value is passed to the callee, why isn't ownership transferred? Could you (in theory) use tagged pointers or some calling convention to tell the callee? I'm not suggesting that's a good idea or even possible, just idle curiosity.

# ? Jan 30, 2015 23:37

Kallikrates: Jul 7, 2002; Pro Lurker

rjmccall posted:

But we do, in fact, detect that and optimize based on it.

The long-term plan is that we'll be able to do a similar analysis to your entire project, so we'd similarly be able to devirtualize anything not public/dynamic.

Thanks, I'll trust you over mikeash

Wish there was a place where all these types of things are laid out. I googled for this info this morning and couldn't find anything other than mikeash's blog post. And I wasn't that interested in dumping compiled output. Over and over when talking about swift I hear the phrase "I heard from a guy..." or "So-and-so said..." about things that are important in using a language and when you ask where they got it from, silence.

# ? Jan 31, 2015 00:22

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

Ender.uNF posted:

If the value is passed to the callee, why isn't ownership transferred?

Our standard convention in Swift does actually transfer ownership. Currently that applies even to self, but we want to change that because it introduces a lot of unnecessary retains and releases; the new convention would be a caller-maintained guarantee that self stays alive. Notably, that would still allow a tail call to a different method on self, since the outer guarantee would still be sufficient for the inner.

The standard Objective-C convention does not transfer ownership, so tail calls to Objective-C methods are harder. (The C++ convention also does not transfer ownership of value arguments. Well, to be precise, MSVC++ does, but the way they do it violates language semantics, and it still doesn't allow tail calls.)

If an argument has to be passed indirectly, e.g. if its type is an unrestricted type parameter or if it contains a weak reference, our convention is still to transfer ownership; however, that doesn't necessarily permit a tail call because the memory for the argument may still be allocated in the calling frame. The major exception is when a call is passing a value taken directly from one of its own arguments, in which case it can generally pass the address of the argument. This isn't currently a very reliable optimization, but it should be a lot better in the coming update.

There are sometimes other kinds of clean-up needed after a call; for example, there are several relating to passing an inout argument. These will all inhibit tail calls.

Ender.uNF posted:

Could you (in theory) use tagged pointers or some calling convention to tell the callee? I'm not suggesting that's a good idea or even possible, just idle curiosity.

To indicate ownership transfer? Yes, you could always just pass an extra parameter saying whether ownership is transferred, mangled into a pointer or otherwise. But it's way better for everyone to just agree on a convention.

Kallikrates posted:

Thanks, I'll trust you over mikeash

Wish there was a place where all these types of things are laid out. I googled for this info this morning and couldn't find anything other than mikeash's blog post. And I wasn't that interested in dumping compiled output. Over and over when talking about swift I hear the phrase "I heard from a guy..." or "So-and-so said..." about things that are important in using a language and when you ask where they got it from, silence.

You'll be getting a tools update soon-ish, and to go with that, we're drafting some performance notes that should be helpful. If you have specific questions, though, feel free to ask.

# ? Jan 31, 2015 01:38

ultramiraculous: Nov 12, 2003; "No..."; Grimey Drawer

Kallikrates posted:

Over and over when talking about swift I hear the phrase "I heard from a guy..." or "So-and-so said..." about things that are important in using a language and when you ask where they got it from, silence.

Yeah, I've been guilty of referring to rjmccall as "some Swift engineer on Something Awful", and I routinely hear people reference Apple dev forums posts that have been lost to time.

# ? Jan 31, 2015 01:48

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

Fact: TCO that isn't a compilation error when the call falls out of tail position (such as by adding something with a destructor to the scope) is a trap and not a feature. Use distinct syntax or suffer for eternity.

# ? Jan 31, 2015 01:52

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

Subjunctive posted:

Fact: TCO that isn't a compilation error when the call falls out of tail position (such as by adding something with a destructor to the scope) is a trap and not a feature. Use distinct syntax or suffer for eternity.

I'm seriously tempted to make "goto function_name(param1, ..., paramN);" to be the syntax for explicit tail calls in the toy language I'm developing. But I'll probably wuss out and call it tailcall or something.

# ? Jan 31, 2015 01:58

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

Subjunctive posted:

Fact: TCO that isn't a compilation error when the call falls out of tail position (such as by adding something with a destructor to the scope) is a trap and not a feature. Use distinct syntax or suffer for eternity.

Completely agreed. Swift does not guarantee tail calls, and if we ever do, they will be explicitly called out.

I'm not worried about people relying on LLVM's casual TCO because it never triggers in debug builds, which ought to set expectations pretty clearly.

# ? Jan 31, 2015 02:05

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

Started new job where our new solution is all Swift. Are we doing something wrong where most of the objects aren't debuggable? I can't do po myObject anymore. Just get a slew of lldb errors. Is it some build configuration setting?

# ? Feb 5, 2015 02:45

Adbot: ADBOT LOVES YOU

# ? May 14, 2024 05:32

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

Doh004 posted:

Started new job where our new solution is all Swift. Are we doing something wrong where most of the objects aren't debuggable? I can't do po myObject anymore. Just get a slew of lldb errors. Is it some build configuration setting?

Check for warnings or problems in your headers. If there's anything amiss it will put lldb into a tailspin.

# ? Feb 5, 2015 03:58

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

«‹›48 »