Upper Bound on Workflows in Xcode 13 #46
Tyler-Keith-Thompson
started this conversation in
Show and tell
Replies: 1 comment
-
|
Obviously these numbers are all subject to change since this is beta Software and because we're testing when the Swift compiler cries and begs for mercy, but it's still helpful to know our limits. I'd say 1,173 item workflows people can create with static Swift code in Xcode 13 is more than enough. I doubt it matters because the compiler should mostly be unaffected but in case it does here's my machine specs: |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
We made the Swift Compiler cry a little with type safety added to Workflow as they grew too large. Apple announced in WWDC that they made improvements to the compiler because SwiftUI kept causing it to say expressions were too complex to evaluate in a reasonable amount of time.
I decided to push their new compiler limits to the extreme and see just how big a Workflow I could grow. I thought I'd share my results
NOTE: To push the compiler to really have to figure out different types here are the FlowRepresentables it had to check against:
Upper Bound on Creating A Workflow Correctly.
RESULT: 1,173 items in a Workflow are VALID with the new Swift Compiler in Xcode 13 🎉.
RESULT: 1,174 items caused it to give an ambiguous error 😮💨
Because it's fun to see, here's just what that code looks like
Upper Bound on Creating A Workflow Incorrectly.
RESULT: Compiler still gives useful error when Workflow is 28 items or less 🎉
RESULT: Compiler gives unhelpful information that ALL LINES are wrong if a single generic error is found in a workflow > 28 items 🤷♀️
RESULT: Despite the completely wrong error information and some amusing Xcode UI glitches the compiler, while slow, does recognize an error with the same upper bound as a workflow created correctly.
Beta Was this translation helpful? Give feedback.
All reactions