ljw1004 posted:

I'm trying to find in the iBook an explanation for the type system of named tuples...

code:

var t1 : (Int,Int) = (2,3)
var t2 : (a:Int, b:Int) = (2,3)
var t3 : (c:Int, d:Int) = (2,3)

t2 = t3 // disallowed
t1 = t3; t2 = t1 // allowed, loophole!
t2 = t3 as (a:Int, b:Int) // don't know; crashes Playground every time, and causes a build failure

Q. Are named tuples considered different types if they have different names? -- apparently yes.
Q. Is the unnamed tuple "t1" a different type from the named tuple type "t2"? -- presumably yes.
Q. Is there an implicit conversion between named and unnamed tuple types? -- apparently yes.
Q. Is there an explicit conversion between differently named tuple types? -- unknown

rjmccall posted:

words

eschaton posted:

I think that was referring to filing intentional duplicates to try to inflate priority, like "this bug is a duplicate of 12345, here's some text copied and pasted from a web site, I vote for this feature too!"

If you are yourself running into a bug or other difficulty, you should always file it, and not worry about whether what you're filing is a dup of something else. (Only don't if you know your exact issue is already known and you've been asked not to—like, say, for access control in Swift.)

Also, don't get caught up spending hours putting together a bug report, a couple sentences is fine if that's all you actually need to specifically describe the issue. If an engineering team needs more detail they'll ask. And push back if a bug comes back to you as fixed but from your perspective it's not.

Finally, if you would like to see a feature/enhancement/change, you should also always file it yourself, and explain your needs clearly; they may not be addressed the way you requested, but they will be taken into account. (This is the reason "why" matters, not just "what.") An example of that from early OS X history was when some developers asked for the Enterprise Objects Framework to be brought forward; what they got was Core Data instead, as a model-level persistence framework for Cocoa.

dizzywhip posted:

I think I finally hit Xcode's breaking point. I can edit code for a few seconds before it crashes, locks up for minutes/indefinitely, or Source Kit Services errors out over and over. Hopefully the next update brings some significant stability improvements. I was still enjoying it even when it was barely usable though, I'm super excited to start transitioning over to Swift full-time for 1.0.

ljw1004 posted:

rjmcall, I really appreciate all your posts in this thread. I haven't yet figured out how to use radar, but I'll do that tonight or tomorrow night and file all the bugs I've posted here so far. Am still completely new to Apple development.

lord funk posted:

Can you quick explain this? I'm falling behind in my Swift blog reading / version updates.

Speaking of, which blogs are you all reading?

ljw1004 posted:

rjmcall Please remove this feature, and instead implement a method ".HasValue" on Optional<T>. That way we can write code that's easy to read:

code:

if x.HasValue {...}

if y.HasValue {...}

Flobbster posted:

Enjoy the huge rent. I thought I could escape it in San Jose (and did for a year!) but it eventually caught up down here too. Now there's no escaping it.

quote:

operator infix !! { associativity left }

@infix public func !!<T>(left: T?, right: T?) -> T? {
return left ? left! : right
}

@infix public func !!<T>(left: T?, right: @auto_closure ()->T) -> T {
return left ? left! : right()
}

var x:String?
var y:String?
let z = "alt"

let a = x !! y !! z

rjmccall posted:

Kallikrates posted:

The example is derived..., the object implementing the protocol is not a plain NSObject. On the API consumer side, knowing its class X implements protocol Y is helpful when you want to call functions of class X and protocol Y without having to cast back and forth between "id<Foo>" and "X" when I get back to my computer with Xcode Beta ill try (protocol<NSObject, Foo>) but I don't think its a solution because the NSObject protocol only exists for base NSObject, not subclasses,

Another example:

code:

extension CustomNSOperationClass {
  func returnsSomethingThatConforms() -> (CustomNSOperationClass, FooProtocol) {

  }
}
//given the return type no as? should be needed
CustomNSOperationClass.returnsSomethingThatConforms().start().fooProtocolMethod()

The major use case is extensions/categories that add protocol conformance.

Another option would be to create a protocol of all the public methods/functions of a class and then use protocol composition, but that's not necessary in Obj-c so I don't think it should be needed in Swift.

swiftc posted:

{a=5, b=1, c=1, d=1, e=1}
{a=5, b=4, c=3, d=2, e=1}
9 vs 15

rjmccall posted:

Can you express that method check using an optional method somehow? If so, it should be as concise as:

Swift code:

notification?.object.hey?()

I'll try to unpack/forward the rest of this later.

rjmccall posted:

Huh. It should definitely be letting you ask for that method with AnyObject-based dispatch. That's a bug.

As a workaround, try just throwing @objc on the implementations of that method that you're hoping to find.

rjmccall posted:

Oh. Yeah. That's true in ObjC, too.

rjmccall posted:

Yes. Is that not true in Swift? If you've declared it somewhere, and exposed it to ObjC with @objc, that's worth a bug.

quote:

It's on the bucket list. Er, at least the list of possible values for payload-less enums is. Meaningfully enumerating payloaded enums would probably require static or dynamic metaprogramming; what's your goal?

rjmccall posted:

That is a really interesting idea, and I have no idea what to tell you. Metaprogramming, I guess.


Yeah, so the issue here is that init() is not the designated initializer for UIViewController, and that hasn't been marked in the headers, so we have to be conservative and assume you know what you're doing. Don't super-delegate to a non-designated initializer.


Ugh. This is so screwed up. The problem is that initWithStyle: does not behave like a designated initializer for UITableViewController, because it doesn't call a designated initializer from its superclass: it calls init, which on UIViewController is a convenience initializer which re-dispatches down to the most-derived class's initWithNibName:bundle:. So, basically, initWithStyle: is not a designated initializer, and when you're super-delegating, you need to be calling the designated initializer, which is initWithNibName:bundle:. I'm sorry this isn't (1) documented and (2) properly annotated in the header.

fleshweasel posted:

The reason is simply that it allows for chaining and reduction of nil checks.

code:

if let foo = object.optionalProperty?.child.methodWhichReturnsAnOptional() {
}

as opposed to

code:

if let foo = object.optionalProperty {
    if let bar = foo.child.methodWhichReturnsAnOptional() {
    }
}

Although I maybe am not expressing the exact situation where an extension on an optional would be useful, I think you can see where it would be. Equivalents to .NET's string.IsNullOrEmpty() and IEnumerable.any() would probably be really common.

Flobbster posted:

I'm always happy to wait for a well-designed general feature than a specific hack I'm really looking forward to what Swift brings to the table w.r.t. generics overall. From what I've already seen in the standard library and what you've talked about wanting to do, I'm hoping that we're going to start getting a lot closer to the power of C++ templates than a lot of other modern languages since then (at least as close as you can get without doing the same substitution-only approach used there).

On that note, I was recently trying to write a generic matrix ADT that would have a fixed size at initialization time, but when I tried to fill the array using the (count:repeatedValue:) initializer, I hit a stumbling block:

code:

class Matrix<T> {
    private let values: [T]

    init(rows: Int, cols: Int) {
        values = [T](count: rows * cols, repeatedValue: T())
    }
}

This obviously fails because there isn't enough information about T to know that it can be parameterlessly-initialized, and a protocol constraint wouldn't help here. Do you have thoughts about this (something similar to concepts?) in your future roadmap?

rjmccall posted:

Closures aren't objects, and so arrays of closures aren't arrays of objects. Arguably we could make this work, since we do allow our native closure type to be implicitly converted to block type, but we don't currently.

...that said, don't do what you're doing. We will convert our native arrays to an object type, but we are not promising that you'll get a consistent object back, especially if you're making structural changes to the array. So it's really, really not appropriate to use as a lock.

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.