[swift-evolution] SE-0005 ==> Please keep well know acronyms capitalized!

[Pavel Kapinos]

Dear Brent,

I am sorry I touched your feelings here. I am here to state my opinion even if others already made their mind. I have just signed up to the list this morning. I will bring up my point again to be clear - well known acronym capitalization is pervasive in Cocoa APIs and as a result enable fast and easy comprehension and writing good quality code. IMO it is quite important for future preservation in Swift 3. Have a good day!

Cheers,
Pavel.

> On May 19, 2016, at 1:38 PM, Brent Royal-Gordon <brent at architechies.com> wrote:
> 
>> Thank you for you encouragement! Please join in to support it **now**!
> 
> I wasn't trying to encourage you to fight. Quite the opposite, actually.
> 
> In order for swift-evolution to work—to make progress on the language and not suck up infinite time—one of the most important things we, as list members, must do is know when to stop arguing about something, even when we've lost. And the time to argue about this was during the drafting and review of SE-0005. There was ample debate on the list about this specific subject, with many positions represented.
> 
> I was on the side that argued for maximally accurate representation of words, including all-caps acronyms even at the beginning of lowercase strings. Others argued that the first word of a non-type should always be lowercase; still others argued that all letters should be lowercase except for the first one after a word boundary, even in an acronym. If we take the example of a "URL handler" property and an "HTML string" type, there were people arguing for `URLHandler` and `HTMLString`, for `urlHandler` and `HTMLString`, for `urlHandler` and `HtmlString`, even for `uRLHandler` and `HTMLString`. And we finally settled on the current convention, `urlHandler` and `HTMLString`, because it was least offensive to everybody: it kept the initial lowercase letter that some people wanted, while also not mixing the case of acronyms and giving a decent indicator of word boundaries.
> 
> This all took up a week or two of the list's time, and even though I didn't win the argument, I don't want to reopen it. It's been argued, it's been settled, and we need to move on to other designs. And you know what? `urlHandler` isn't *that* bad. It's not what I would have chosen, but it's something I can live with.
> 
> In general, I do not support reopening designs which have already been settled by a formal proposal, review, and core team acceptance, unless the decision is either egregiously bad (I can't think of any examples off the top of my head; perhaps the issues which led to the `form` prefix might qualify) or later experience has shown the design to be worse than previously thought. I will fight a design tooth and nail while it's being proposed and reviewed, but once it's accepted, I put aside my feelings, accept the proposal as part of the language's design, and move on with it. It's the only way we can get anything done here.
> 
> Rehashing old decisions like this is just spinning our wheels. There are lots of exciting new things we *haven't* decided—things like multiline string literals, Foundation and Dispatch designs, and a world of syntax clean-ups. Let's focus on those things—things where we can make forward progress, not keep revisiting old arguments.
> 
> -- 
> Brent Royal-Gordon
> Architechies