The memory allocation can fail, but I think Swift doesn't handle that cases. (it is not a real issue in a modern OS)
Not on a modern 64-bit desktop OS, but it can be an issue on some other platforms. In a 32-bit process (still supported on iOS and Mac OS) malloc can fail if the process's address space is fragmented enough that there are no free blocks large enough for the allocation. On an OS without a VM pager, like many embedded systems, malloc can fail if physical RAM is exhausted.
(I’m actually not sure if this is the reason why that initializer is failable. It’s possible this is a mistake, or Apple’s frameworks team had some other architectural reason for allowing it to fail. Historically, the design pattern for initializers in Objective-C always allows them to return nil.)
The code on github calls a non failable initializer.
That’s for the native-Swift Foundation framework coming in Swift 3. I’d guess they’ve adopted the same method signature as in Apple’s Foundation, for compatibility.
—Jens
···
On Apr 14, 2016, at 10:45 AM, soyer via swift-users <swift-users@swift.org> wrote:
The memory allocation can fail, but I think Swift doesn't handle that
cases. (it is not a real issue in a modern OS)
Not on a modern 64-bit desktop OS, but it can be an issue on some other
platforms. In a 32-bit process (still supported on iOS and Mac OS) malloc
can fail if the process's address space is fragmented enough that there are
no free blocks large enough for the allocation. On an OS without a VM
pager, like many embedded systems, malloc can fail if physical RAM is
exhausted.
(I’m actually not sure if this is the reason why that initializer is
failable. It’s possible this is a mistake, or Apple’s frameworks team had
some other architectural reason for allowing it to fail. Historically, the
design pattern for initializers in Objective-C always allows them to return
nil.)
The code on github calls a non failable initializer.
That’s for the native-Swift Foundation framework coming in Swift 3. I’d
guess they’ve adopted the same method signature as in Apple’s Foundation,
for compatibility.
Swift’s policy on memory allocation failure is that fixed-size object allocation is considered to be a runtime failure if it cannot be handled. OTOH, APIs that can take a variable and arbitrarily large amount to allocate should be failable. NSData falls into the later category.
-Chris
···
On Apr 14, 2016, at 10:45 AM, soyer via swift-users <swift-users@swift.org> wrote:
Swift’s policy on memory allocation failure is that fixed-size object allocation is considered to be a runtime failure if it cannot be handled. OTOH, APIs that can take a variable and arbitrarily large amount to allocate should be failable. NSData falls into the later category.
Swift’s policy on memory allocation failure is that fixed-size object allocation is considered to be a runtime failure if it cannot be handled. OTOH, APIs that can take a variable and arbitrarily large amount to allocate should be failable. NSData falls into the later category.
Does this principle apply to Array(repeating:count:)?
Array.append(contentsOf:)?
Swift’s policy on memory allocation failure is that fixed-size object allocation is considered to be a runtime failure if it cannot be handled. OTOH, APIs that can take a variable and arbitrarily large amount to allocate should be failable. NSData falls into the later category.
Does this principle apply to Array(repeating:count:)?
Array.append(contentsOf:)?
I might split the difference here: trying to append a very large sequence would be a programmer error, but trying to allocate a very large array might not be.
UnsafeMutablePointer.init(allocatingCapacity:) is also currently non-failable.
Jordan
···
On Apr 15, 2016, at 10:36, Dmitri Gribenko via swift-users <swift-users@swift.org> wrote:
On Fri, Apr 15, 2016 at 10:34 AM, Chris Lattner <clattner@apple.com <mailto:clattner@apple.com>> wrote:
On Apr 14, 2016, at 11:22 PM, Dmitri Gribenko <gribozavr@gmail.com> wrote:
On Thu, Apr 14, 2016 at 11:16 PM, Chris Lattner via swift-users >>> <swift-users@swift.org> wrote:
On Apr 14, 2016, at 10:45 AM, soyer via swift-users <swift-users@swift.org> wrote:
Swift’s policy on memory allocation failure is that fixed-size object allocation is considered to be a runtime failure if it cannot be handled. OTOH, APIs that can take a variable and arbitrarily large amount to allocate should be failable. NSData falls into the later category.
Does this principle apply to Array(repeating:count:)?
Array.append(contentsOf:)?
As you know well enough, “no”. :-)
Why? These APIs also "take a variable and arbitrarily large amount to
allocate".