ash_gti

Trying it locally for example:

  # Original example
  $ time swiftc -typecheck - <<-HERE
  let address = "127.0.0.1"
  let username = "steve"
  let password = "1234"
  let channel = 11
  
  let url = "http://" + username
              + ":" + password
              + "@" + address
              + "/api/" + channel        
              + "/picture"
  
  print(url)
  
  HERE
  <stdin>:6:5: error: the compiler is unable to type-check this expression in reasonable time; try breaking up the expression into distinct sub-expressions
   4 | let channel = 11
   5 | 
   6 | let url = "http://" + username 
     |     `- error: the compiler is unable to type-check this expression in reasonable time; try breaking up the expression into distinct sub-expressions
   7 |             + ":" + password 
   8 |             + "@" + address 
  swiftc -typecheck - <<<''  36.38s user 1.40s system 96% cpu 39.154 total
  
  # Adding a type to one of the expression values
  $ time swiftc -typecheck - <<-HERE
  let address = "127.0.0.1"
  let username = "steve"
  let password = "1234"
  let channel = 11
  
  let url = "http://" + username
              + ":" + password
              + "@" + address
              + "/api/" + String(channel)
              + "/picture"

  print(url)
  
  HERE
  swiftc -typecheck - <<<''  0.11s user 0.03s system 74% cpu 0.192 total

The reason this causes issues with the type checker is it has to consider all the possible combinations of the `+` operator against all the possible types that can be represented by an inferred integer literal.

This is whats causing the type checker to try every possible combination of types implementing the `+` operator, types implementing `ExpressibleByIntegerLiteral` and `ExpressibleByStringLiteral` in the standard library. That combination produces 59k+ permutations without even looking at non-standard library types.

If any of the types in the expression had an explicit type then it would be type checked basically instantly. Its the fact that none of the values in the expression have explicit types that is causing the type checker to consider so many different combinations.

Specifically, `channel = 11`, an integer.

If it was a string then it parses very quickly.

Webkit is doing pretty good on https://wpt.fyi/interop-2022 so I'm not sure why Safari should be retired.

Has additional context on this proposal and has previously been linked here.

I guess I should say that clang's ARC doesn't apply to these c++ wrappers.

The c++ code is loading symbols using the objc runtime API's to load symbols and call objc runtime APIs to dispatch the metal calls. So, you could pass these references to other objc code and it should have the correct refcounts afterwards.

Having to manually retain/release objects is a bit of a pain, but its workable.

Using a c++ RAII type to retain/release is also somewhat do-able, but I worked in a codebase that had that kind of code and it can be frustrating to get the refcounts to be correct synchronized. Although that was back with c++11, so I'm sure things have changed that would make this easier today.

Swift and obj-c have the same ARC semantics, so I'm not sure what you mean by swift-style refcounting. It should be identical to the obj-c ARC semantics.

https://clang.llvm.org/docs/AutomaticReferenceCounting.html outlines the ARC semantics, including the autorelease behavior.

In obj-c or swift, ARC would handle that for you, so this makes the memory management aspect of using Metal a bit more of a headache.

That's like how Catalysts runtime wasn't backported to older versions of macOS.

They could decouple those frameworks from the OS, but that adds other headaches and you eventually gotta draw the line somewhere so they tend to only add new frameworks with major OS updates.

It has a runtime API that should work with different versions of the OS. There were changes to the compiler that they didn't talk about until after the fact though. After SwiftUI was announced they did run those through swift-evolution.

SwiftUI for the most part is just a runtime library, the compiler changes made things a bit nicer, but most of it could be achieved without compiler changes.

As a consumer, I see that as a feature not a bug. On the Switch, Play Station and Xbox I don't have other stores I can use as well. I don't see how this is a problem as much as it is a feature. The fact that Android allows more than one store is much closer to how a Windows PC allows the user to install apps from anywhere. iOS isn't trying to replicate the PC experience, its not nearly as general purpose as Windows or even macOS.

Maybe not the best language for someone new but its widely available.

I suspect they didn't want to conflate the two types.

That's different than the linked page but I think it gets across the changes that are coming.