6 ms·

The recent Swift updates add increasingly niche and theoretical features that are of questionable practical use. Meanwhile the compiler still can't compile man

• almostgotcaught 2y ago
  you think C++ interop is niche? lol
  • IshKebab 2y ago
    Well, in fairness I would probably take "error messages point to a file location" over "lifetime annotations for C++ FFI".
  • tomovo 2y ago
    For regular Swift developers who make iOS apps, yes it's niche. C++ interop is probably more important for Apple itself. Swift compiler speed and error reporting are abysmal and improving them would have a much bigger impact. So far it's not getting any better at all. If I could give up some level of type inferrence and get the build time from 3 minutes to 20 seconds, I would.
    • jb1991 2y ago
      It’s not that niche at all if you have a cross platform app or you have a big part of your app that has to interface with metal kernel code, which is C++. There are a lot of reasons why you would want that code accessible from swift as well. And it’s also a big deal in games, communicating between swift and C++ is necessary unless your game only exists on iOS.
      • tomovo 2y ago
        Sure, I like the C++ interop and agree that it's important. My point was that 99% of Xcode/Swift app developers will never touch it or even know it's a thing.
• wrasee 2y ago
  C++ is hardly niche, nor I would say is the desire to interop with large, established languages with decades of existing code and libraries. As someone who has worked in both Swift and C++ I’m grateful for those that choose to make an effort in this space. And of course, just because some do doesn’t take away from others that work on SwiftUI. Both can be true at the same time.
  • quietbritishjim 2y ago
    Agreed that C++ FFI is not niche, although it's also not really a core feature (C FFI suffixes for that). Safe FFI with lifetime support is definitely lower priority though, given that FFI is usually in a thin layer of application code that can sort out safety itself.
    • Someone 2y ago
      > given that FFI is usually in a thin layer of application code that can sort out safety itself. Apple is aiming far higher. They want [1] the ability to seamlessly replace C++ code anywhere with Swift code, to write subclasses of C++ classes in Swift, etc. without giving up performance. See https://github.com/swiftlang/swift-evolution/blob/main/visions/using-swift-from-c%2B%2B.md#goals https://github.com/swiftlang/swift-evolution/blob/main/visio... and the video linked to in https://forums.swift.org/t/video-swift-as-c-successor-in-foundationdb/67823 https://forums.swift.org/t/video-swift-as-c-successor-in-fou..., which shows how far they were a year ago. [1] they likely won’t get there for all C++ code, but if they get to “with a few manual annotations” without giving up efficiency, that would be a major accomplishment.
• johnisgood 2y ago
  > "The compiler is unable to type-check this expression in reasonable time" Lol this sounds funny, any other compilers that do this? Why does this happen exactly? > It does not even tell you what part of code it is having issues with so you could change it. You have to comment/uncomment blocks of code to find the problematic part. Awful.
  • wrasee 2y ago
    You’re aware that the comment was specific to (I would say) reasonably complex SwiftUI expressions? How familiar are you with the context here?
    • johnisgood 2y ago
      So you are saying this is specifically limited to SwiftUI? This fact does not make it any less absurd, especially with the last part that has been said. My question stands: why does this happen and how come it is still so primitive that you do not even get to know the location of the issue?
      • jmillikin 2y ago
        https://danielchasehooper.com/posts/why-swift-is-slow/ https://danielchasehooper.com/posts/why-swift-is-slow/
        • johnisgood 2y ago
          Thank you! let result: Double = -(1 + 1) + -(1 + 1) - 1 > Swift 6 takes 6.2 seconds to compile this one line. Even toy languages compile equivalent expressions faster. Wild. :P
          • happytoexplain 2y ago
            Note that, while this is definitely crazy, it's rare in practice if you avoid gluing a bunch of magic literals together using operators, which I already avoided as a habit. I've never encountered the exploding-compile-time issue once while writing production Swift, which I have done almost every day for a decade. WITH THE EXCEPTION OF SWIFTUI, which relies entirely on inferring highly nested generic types, and stands out as a uniquely problematic Swift framework for that and other reasons. I don't use SwiftUI.
• alkonaut 2y ago
  The same could be said for the similar C# and .NET features. The practical use for many low level constructs is for library authors, which is perhaps 1 developer out of 1000, but those libraries are used by the 999 others which means the "practical use" of the feature is a lot more than it would seem at first sight. > Meanwhile the compiler still can't compile many even mildly complex SwiftUI views and expressions with the "The compiler is unable to type-check this expression in reasonable time" error. That seems like a bug in language design? What's the story behind that? Did they inadvertently make something that was quadratic or worse and then realized it was too late or too fundamental to fix it properly so they patched it over with an error message?
  • johnisgood 2y ago
    > That seems like a bug in language design? What's the story behind that? Did they inadvertently make something that was quadratic or worse and then realized it was too late or too fundamental to fix it properly so they patched it over with an error message? This is what I would like to know, too, but you phrased it way better than I did.
    • aapoalas 2y ago
      Here's a good blog post on the issue: https://danielchasehooper.com/posts/why-swift-is-slow/ https://danielchasehooper.com/posts/why-swift-is-slow/
      • johnisgood 2y ago
        Yeah I have read this not long ago, it is a great post. > A different approach to type checking is required to fix it. I agree, are they actively working on this though?
        • int_19h 2y ago
          I don't see what they can do about this in general, short of requiring sufficient explicit type annotations to mitigate the combinatorial explosion of possible combinations. But if that is an acceptable solution, you can already add such annotations to your code regardless. C# actually has a similar issue with lambdas passed to generic functions, for similar reasons. It's just what you get when you combine overload resolution with type inference.
• jmull 2y ago
  Swift just lets you use type inference liberally, which is nice, IMO. (Go ahead and opt-out if you disagree.) The problem you describe is more with the design of SwiftUI, which makes massive, complex, extenuated use of the type system. The types quickly become too complex to reason about. It's a mess that hinders the developer instead of helping them. Not what you're going for when you design an API. Apple really screwed this one up, though I doubt they will backtrack to fix it, so we're probably stuck with it.
• hn-acct 2y ago
  Most of the time you just need to break up the view into smaller pieces. Eventually you realize you have a syntax error ;)
• conradev 2y ago
  C++ interoperability is neither niche nor theoretical. I imagine it would allow them to rewrite bits of the existing compiler, written in C++, into Swift. The type inference time explosion issue is a known and well-documented flaw. Fixing it would require an overhaul of the type system, which is possible, but I’m not sure if there is appetite for it.