> On May 6, 2016, at 12:04 AM, David Hart <[email protected]> wrote: > > I understand why the alternative of changing the generic type parameter list > symbols was rejected, to be consistent with other C based languages, but I > don't understand why the following was rejected: > > • making the UppercaseTypes, lowercaseValues convention a syntactic > requirement, as is done in ML and Haskell. > I see that as a good viable alternative.
The challenges with making that work include: - Deciding what to do with imported C APIs. Core Foundation uses CFUppercaseEverything, and POSIX prefers snake_case_t and snake_case_functions. In the early days, we were shy about transforming imported APIs at all, but we've obviously gotten more comfortable with it as Swift's established itself and its own conventions have emerged. - Providing an alternative for non-Latin scripts that don't differentiate case, such as Arabic and Chinese (and, somewhat related, deciding whether non-letter identifier characters like emoji are "value" or "type" characters). -Joe _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
