[ChrisMarshallNY]

Makes sense, and it is annoying, but there’s a lot of annoying stuff in Xcode. Looking at the console can get rather depressing. There’s a lot of “noise” in there, that is basically sound and fury, signifying nothing. I get tired of googling errors and warnings (I compile -wall, and take every warning seriously), only to realize they are meaningless “background noise,” due to the system trying to generate code for platforms other than the target, for instance. In those cases, Xcode usually won’t interrupt the build, just spit out an annoying warning.

Xcode is a huge, chimeric monster. I seriously doubt there’s anyone, anymore, that really knows what’s going on under the hood. It’s larger than many games, which says a lot.

That said, I regularly use it to produce fairly concise, performant applications, and I can bear the pain.

Here’s an example of me encountering an annoying warning[0], and being told “you’re holding it wrong.” I was basically chided for my style, which, I guess, is one PoV, but I feel didn’t actually answer the question, and, in my opinion, is pretty much irrelevant to the point.

[0] https://stackoverflow.com/questions/79275128/is-there-a-way-...

[ninkendo]

> Looking at the console can get rather depressing

Opening Console and watching critical error messages stream in at an alarming rate when you do basically anything in the entire OS, is a great way to remind yourself just how bad Apple’s software quality has gotten. They're absolutely drowning in bugs.

I just opened it, after waking my laptop up from sleep, and about 10,000 errors+warnings have streamed in in the past 30 seconds or so. I'm doing nothing, just a single Safari window with this tab and nothing else going on.

(It would be interesting to see a graph of “errors per second while doing nothing” over each yearly release.)

[thedanbob]

I'm getting really fed up with all the bugs in Sequoia in particular. I know the usual advice is to not upgrade macOS major versions until .1 or .2, but we're up to 15.3.1 now and it's still terrible.

[emchammer]

I hate to be pessimistic but I have to agree. I have filed a number of bug reports, about Logic Pro for example. I try to be detailed and a number of them should have been real gimmes, but it seems that half the time somebody just asks for a crash dump or example file to ignore it.

[mistrial9]

but it is all a success! (customers are paying money for products) /s

[robenkleene]

The example warning is the Swift language warning about style conventions, there's an interesting conversation about whether enforcing style conventions through warnings is appropriate, but that's is a Swift language question, not an Xcode question.

[hulitu]

> Makes sense,

For you maybe. Why it makes sense ? Are Xcode developers not able to test their code ? Does Apple need to know who you talk to, what are you writing or what did you eat ?

[ChrisMarshallNY]

> For you maybe

I like to ship, and that requires a lot of interaction with Apple servers.

Provisioning is a pain, and, speaking only for myself, I'm fairly happy that Apple has made that easier (by doing a lot of the handshake behind the scenes).

But, yeah, if you don't want to ship, then you probably only want interactions for things like documentation and dependency versioning.

[saagarjha]

I mean you're going to tell me that this a rehash of what the Stack Overflow people told you but the reason this is a warning is because the external name is meant to aid in readability but the internal name is the one that is actually operated on, so the latter is the one that is actually relevant when documenting what the thing actually is. It would be unreasonable to write documentation for a parameter called "in" (internal name: range) or "behind" (internal name: window). So yeah, you're holding it wrong. If you disagree you should do one of two things:

1. Ask for a way to use the external name as documentation. (This is not a serious suggestion, because if you go do this people will laugh at you and tell you to stop doing that. But you could do it.)

2. Ask for a way to turn off warnings. (This is a reason suggestion, I actually want this. Unfortunately the answer that you really want is "no you can't do this".)

[ChrisMarshallNY]

Yeah, you can look at it that way, but API documentation is for external users, and I prefer to reduce the number of inline comments, inside the function, which is not where the external users will be going, anyway.

Most folks will only care about the external name. The internal name is for maintainers. It not only indicates the value is a constant, it also tells you that it has not been altered since entering the function body, and that's pretty important. The "in" prefix regularly saves me from assigning the unprocessed value, instead of one that has had some conditioning applied.

No matter. As long as the warning doesn't bork the build, I can live with it.

I could probably provide protocols for API documentation, but protocols have their own issues[0].

[0] https://littlegreenviper.com/the-curious-case-of-the-protoco...

[saagarjha]

I only skimmed this but you might be able to leverage @_implements here?