Also there's code in here that copies the struct properties to local variables, with a comment // ensure NO ivars of self are actually captured, and it's not clear why it does this either as the only blocks involved here are withUnsafeMutablePointer which is noescaping.

Another potential concern: if I have an NSFastEnumerationIterator I can access next() after it's already returned nil, which will cause it to invoke countByEnumerating(with:objects:count:) repeatedly. The problem with this is NSFastEnumeration isn't designed with the expectation that you'll ever invoke the method again (with the same state) after it's returned 0. While this is probably ok with the built-in collections, it seems potentially problematic to assume it's always safe.

The following seems like a much more faithful translation of the Obj-C version (completely untested of course):

public struct NSFastEnumerationIterator : IteratorProtocol {
    var enumerable: NSFastEnumeration
    var objects: (Unmanaged<AnyObject>?, Unmanaged<AnyObject>?, Unmanaged<AnyObject>?, Unmanaged<AnyObject>?, Unmanaged<AnyObject>?, Unmanaged<AnyObject>?, Unmanaged<AnyObject>?, Unmanaged<AnyObject>?, Unmanaged<AnyObject>?, Unmanaged<AnyObject>?, Unmanaged<AnyObject>?, Unmanaged<AnyObject>?, Unmanaged<AnyObject>?, Unmanaged<AnyObject>?, Unmanaged<AnyObject>?, Unmanaged<AnyObject>?) = (nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil)
    var state = NSFastEnumerationState(state: 0, itemsPtr: nil, mutationsPtr: nil, extra: (0, 0, 0, 0, 0))
    var index = 0
    var count = 0
    var mutationsPtr: UInt? = nil

    public init(_ enumerable: NSFastEnumeration) {
        self.enumerable = enumerable
    }

    public mutating func next() -> Any? {
        if index >= count {
            index = 0
            count = withUnsafeMutablePointer(to: &self.objects) {
                let buffer = AutoreleasingUnsafeMutablePointer<AnyObject?>($0)
                return enumerable.countByEnumerating(with: &state, objects: buffer, count: 16)
            }
            if count == 0 { return nil }
            if mutationsPtr == nil {
                mutationsPtr = state.mutationsPtr.unsafelyUnwrapped.pointee
            }
        }
        if state.mutationsPtr.unsafelyUnwrapped.pointee != mutationsPtr.unsafelyUnwrapped {
            objc_enumerationMutation(enumerable)
        }
        defer { index += 1 }
        return state.itemsPtr.unsafelyUnwrapped[index]
    }
}

Yeah, this looks a lot better. I assume state.mutationsPtr was being set to something non-nil because of incorrect nullability at one point, but it might have just been a misunderstanding of the API from the beginning.

The one reason I can think of to not always go through itemsPtr is that the optimizer can tell that's an exclusive access, but when we're talking about NSFastEnumeration I'm not sure how much that matters in practice. You only access each item once anyway.

If we want to avoid the "calling next() at the end will call countByEnumerating(with:objects:count:) again" problem, we could check if count == 0 && mutationsPtr != nil. That means we've called it at least once already. (Also, the local value isn't really a pointer; it's more a mutationState or something.)

cc @millenomi, @Catfish-Man

This looks good to me, without having done a full comparison to the existing code. Thanks Lily!