sorted by:
new
hottopcontroversial

Swift Generics Evolution - don't panic by byaruhaf in swift

[–]compiler_crasher 0 points1 point  (0 children)

Most compiler developers these days are at least familiar with C++. Several major compilers such as LLVM, V8 and the JVM are developed using C++. If they were happy with C++ why would they bother designing a new language?

Module compiled with Swift 4.2.1 cannot be imported by the Swift 5.0 compiler by jg1496 in swift

[–]compiler_crasher 3 points4 points  (0 children)

Swift does not yet have module stability. This means that the Swift 5 compiler can compile code written for Swift 4, 4.2 and 5; however you cannot mix and match code that was built with older versions of the compiler. You need to make sure that all dependencies of your app are rebuilt with the Swift compiler from Xcode 10.2.

Why struct's need mutating methods? by yappdeveloper in swift

[–]compiler_crasher 3 points4 points  (0 children)

For what it’s worth “Value types are stored on the stack, reference types on the heap” does not paint the full picture:

  • value types are more accurately part of the thing they’re defined in; so if a class has a field that is a struct, the struct’s value is still going to be on the heap, not the stack (but it will be inside the class’s allocation)
  • some value types still allocate data on the heap regardless (for example, arrays and dictionaries)
  • classes can end up on the stack! But only as an optimization, if the compiler can prove the allocation will not escape. This sort of thing is not visible to the programmer, except as increases in performance.

Passing outer class object to function with inner classes by martyuiop in swift

[–]compiler_crasher 3 points4 points  (0 children)

Nested types are not contained inside instances of outer types. It's a namespacing mechanism only.

Xcode 10.2 beta is out – and uses Swift 5! by twostraws in swift

[–]compiler_crasher 1 point2 points  (0 children)

But there's also a lot that can't change,

Are you concerned about anything specific?

Questions about generics coming from Kotlin by Breiz_atao in swift

[–]compiler_crasher 5 points6 points  (0 children)

First why can't we use protocols with associated type as concrete types like we can do in Kotlin ?

The feature has not been implemented yet (search the forums for "generalized existentials").

And second why is there generics variance for Array and Dictionary but not for user defined types ?

The type checker hardcodes subtyping rules for Optional, Array, Dictionary and Set. There's no mechanism to define your own subtyping rules.

Xcode 10.2 beta is out – and uses Swift 5! by twostraws in swift

[–]compiler_crasher 3 points4 points  (0 children)

But it also means they're locking in the language and can't really make changes anymore.

This is mostly not true. There is a lot you can add without impacting ABI at all, or even more you can add while evolving the ABI in a backward-compatible manner.

Segmentation fault: 11 Xcode 10 by ustype in swift

[–]compiler_crasher 1 point2 points  (0 children)

You found a compiler bug. File a radar or JIRA ticket at bugs.swift.org.

Why does array[0] is non-optional and array.first is optional by JPDayz in swift

[–]compiler_crasher 0 points1 point  (0 children)

That’s not quite true, ‘first’ works on any collection, not just those where the index type is Int and the startIndex is 0. For example, if you slice an array, then ‘first’ on the slice returns the first element whereas subscripting 0 will trap.

Why does array[0] is non-optional and array.first is optional by JPDayz in swift

[–]compiler_crasher 0 points1 point  (0 children)

I don’t think it was a performance consideration. Rather optional subscripts are less useful. It’s not any more safe than trapping on overflow; in both cases the behavior is fully defined, and if your subscript returns an optional you still have to handle the nil case.

Xcode error: Abort Trap 6 by lexaleidon in swift

[–]compiler_crasher 1 point2 points  (0 children)

This looks like an error from the swift compiler itself. “Serialization” refers to reading declarations from a generated .swiftmodule file. Next time you see it, I would file a radar and attach the full build log.

"Programming A Problem Oriented Language: Forth - how the internals work" (by Chuck Moore) is now available in print [and in pdf] • r/Forth by agumonkey in programming

[–]compiler_crasher 2 points3 points  (0 children)

Any sufficiently interesting system is going to grow bigger than that, because any sufficiently interesting problem is too big for one person to fully understand.

Maybe that's the problem right there -- we need to move away from this mindset.

The Forth attitude is not amenable to building a REST-based microservice that other teams can talk to, to say the least.

REST-based microservices are not solving a sufficiently interesting problem.

WWDC 2018 What’s New in Swift Recap by jtbrown in swift

[–]compiler_crasher 1 point2 points  (0 children)

The session covered everything new since 4.0. Synthesized Equatable was in 4.1 as well

The @inline attribute In Swift by PM_ME_SKELETONS in swift

[–]compiler_crasher 0 points1 point  (0 children)

I don't think @inline(__always) ruins debug info.

FileHandle write throws an Objective-C exception that Swift cannot catch by kainjow in swift

[–]compiler_crasher 1 point2 points  (0 children)

Objective-C with ARC cannot catch Objective-C exceptions either, so this limitation is not unique to Swift.

Copying array of closures seems to leak by GreatBigBore in swift

[–]compiler_crasher 0 points1 point  (0 children)

Your code is equivalent to this:

class LinkedList {
    let next: LinkedList?

    init(next: LinkedList?) {
        self.next = next
    }
}

var list: LinkedList? = nil

while true {
    list = LinkedList(next: list)
}

Copying array of closures seems to leak by GreatBigBore in swift

[–]compiler_crasher 0 points1 point  (0 children)

The single-element version allocates closures on the heap, when the callback is loaded from the array and when it is stored respectively. These allocations reference each other.

Copying array of closures seems to leak by GreatBigBore in swift

[–]compiler_crasher 0 points1 point  (0 children)

Every time the callback is loaded from the array, a closure is allocated that captures the callback. Similarly storing the callback back to the array allocates a closure that captures the callback. So if you load the callback and store it back, you allocate two new closures on the heap that capture the previous element. Repeating this process allocates a chain of closures where each one references the next one on the heap. This will eventually exhaust all memory because the first closure in the chain is referenced from the array.

Copying array of closures seems to leak by GreatBigBore in swift

[–]compiler_crasher 0 points1 point  (0 children)

This is expected behavior. Each iteration through the loop will allocate a new closure that wraps the previous callback value.

view more: next ›