I've spent 3 or 4 days working on a issue that came down to this message 'V' could not be inferred. The problem turned out to be the compiler couldn't take the time to tell me the Transaction model did NOT have a property 'quantity' (it was changed to 'shares'). I found this out when I started factoring out pieces of the View into components... in this case when I got to creating a TransactionRow View the simplified code could be compiled and the 'quantity' property got flagged as non existent. Wow - such a bad compiler message. Had me thinking my Query properties were bad. Lesson I hope to learn - when things go to crap... simplify!

I'm pondering this question in relation to a Protocol associated with CloudKit. I want a name for a protocol - like Coadable - is used for JSON to/from Objects. My desired protocol NAME will ensure that the Object implements the ability to be Instantated from a CKRecord and has a readable property that is a CKRecord. I'm pondering sticking with the Cloud metaphore... // Other options for a Protocol name: Precipitable, Materializable, dematerialize, evaporable, Sublimation // capabile of being  instantiated by CloudKit (from cloud to actual) & Sublimation (solid > gas phase change) protocol CKPrecipitable {     init?(record: CKRecord)     var record: CKRecord { get } } What's you opinion?

I turned off Indexing in Xcode with: david@Mac ~ % defaults write com.apple.dt.XCode IDEIndexDisable 1 This appears to have given the compiler enough CPU to complain about one of my Swift Views.

I've been struggling with this issue for days now. Running down all kinds of attempts... I can NOT say this was a general resolution. I turned off Indexing in Xcode with: david@Mac ~ % defaults write com.apple.dt.XCode IDEIndexDisable 1 And later after the code fixes back on by quiting Xcode and running: david@Mac ~ % defaults write com.apple.dt.XCode IDEIndexDisable 0 This appears to have given the compiler enough CPU to complain about one of my Swift Views. It was not compiling - nor showing errors in the IDE editor. So when it finnaly got enough CPU to complain and I started fixing... One of the complaints was the SwiftUI classic: "The compiler is unable to type-check this expression in reasonable time; try breaking up the expression into distinct sub-expressions" So that complaint was at the top of a View... so I successfully decomposed the view. And compiling started happening again. I turned back Indexing On - it controls autocomplete and other useful IDE features you will want. Good luck!

Does anyone know how the other apps do this? 100 | | 50 | | 0 |_______________________ Th F M T W Th F Maybe I don't know how to ask the right/best question. I want to plot price data with the latest price on the right and skipping weekend days (Sat. and Sunday). Any ideas?

I've started see these similar error in Xcode 14 BETA. Trailing closure passed to parameter of type 'HorizontalAlignment' that does not accept a closure I've resolved it once by wrapping my contents inside a Group {} - SwiftUI block. ... might work...

I have Xcode Version 13.3 (13E113) and have a similar compiler error Expected declaration on line:  if #available(iOS 15, *) { Inside a View struct. FYI.

this kind of info helps so much when pair/mob programming - and remote coding! I'd love to know if anyone has an app for this? E.G Jetbrains 7345 Presentation Assistant

Hello all, I'm wanting to code something similar.  Right now I have a List - which does a vertical scroll just naturally.  I assumed (what an ) that I'd just add a modifier to make List(.horizontal) but the compiler rejected that real fast.  That resulted in about 6 google searches (one found this thread) with no easy results.  Next (should have been first) went to Mark Moeykens Swift UI Views Mastery book (awesome resource) - quickly found that I needed to sub out the List for a ScrollView that can do HORIZONTAL!!  But my first Purview/Canvas test proved it was not just a drop in replacement for List.  It compiled but the views I have in the list display with differently colored white space. So now that I've a view that can handle up&down as well as side-to-side... I need the env to tell my view which one it should use. I'm confused by the Apple docs... (imagine that Apple - - take some of the nest egg and hire some Tech-Writers for the developers you make so much money with!) what the heck is this trying very hard to tell me??  UIInterfaceOrientation Starting in iOS 8, you should employ the UITraitCollection and UITraitEnvironmentAPIs, and size class properties as used in those APIs, instead of using UIInterfaceOrientation constants or otherwise writing your app in terms of interface orientation. Important -in a nice ugly yellow box- Notice that UIDeviceOrientation.landscapeRight is assigned to UIInterfaceOrientation.landscapeLeft and UIDeviceOrientation.landscapeLeft is assigned to UIInterfaceOrientation.landscapeRight. The reason for this is that rotating the device requires rotating the content in the opposite direction. This UIInterfaceOrientation.isPortrait seems like the call I'd want to shove into the ScrollView   ...   ScrollView( UIInterfaceOrientation.isPortrait ? .horizontal : .vertical ) { ... } I'm trying to decipher the  notes ... about versions ... is it supported ?  is it supported in 14+ and beyond?  Or am I that can not understand the docs English?