What's the idea behind the changes in the Objective-C flavor of the Foundation documentation?

Does it matter? You can use true, TRUE, YES and yes, can't you?

Besides, saying something is 'true' makes more sense in a sentence describing the effect of some function, rather than 'yes'.

a BOOL used to be YES or NO for the last quarter of a century

It's still YES or NO.

If I'm writing ObjC I use YES/NO. If I'm writing Swift I use true/false. I think it's personal preference at this point.

IMHO, it matters considering that:

• this is the Objective-C flavor of the documentation.
• the prototype of the method returns a BOOL.
• the title of the chapter is "Return value". The type is a BOOL.
• for more than 30 years, it has been YES or NO (e.g. https://www.nextop.de/NeXTstep_3.3_Developer_Documentation/Foundation/Classes/NSDictionaryClassCluster.htmld/index.html).

It's a documentation so I don't see how the fact that TRUE, true, YES or 1 are all the same matters.

Modern developer docs are created using DocC. That has a bunch of benefits, but it also has some limitations. One of those limitations is that there’s no direct syntax for inserting a Boolean value and have it automatically map to the user’s preferred language.

Personally my preferred way of dealing with that is to use Boolean, true, and false, so it’s clear that I’m talking about the abstract concept of a Boolean rather than any specific language. However, other folks have other opinions.

Clearly you have your own opinion about this and I recommend that you write that up as a Feedback Assistant report. Please post your bug number, just for the record.

Also, keep in mind that DocC is an open source tool, allowing you to have your own say in how it evolves. If you’d like to get involved, bounce over to the Development > DocC topic area on Swift Forums.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Is DocC also responsible for the gotoNextPane and gotoPreviousPane methods of InstallerPane (InstallerPlugins framework) being weirdly defined as readonly properties?

Already filed another feedback ticket about that one.

FB17227493

Thanks for that.

What was its bug number?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"