![]() ![]() Implementation (WIP): johnno1962:character-literalsII.Authors: Kelvin Ma ( taylorswift), Chris Lattner ( Chris_Lattner3), John Holdsworth ( johnno1962).SE-240 Integer-convertible character literals Since option 4 seems to be the most popular, I’ve rewritten the proposal document based on it, which can be viewed here ![]() stripping them out realistically is just gonna put us back where we started and all these things are just gonna get rehashed anew. This thread has 3631637642 posts because influential people wanted these features in the proposal. so i don’t think having let c:Character = '□□□' error out is going to fly. they did not want to see single quotes limited to just the U+0 to U+128 single codepoint range. There’s a bunch of people (especially in the core team) who wanted to extend the single quote syntax to cover Unicode.Scalar and Character, so that these (important!) types finally get a dedicated literal syntax instead of having to write as Character everywhere. so i don’t think let s:String = 'ab' is going to fly. these people were only placated by appealing to the C (and basically every other language) precedent where single quotes are for “single objects” and double quotes are for “vector objects”. There’s a bunch of people who didn’t want to use up the single-quote syntax on “something as niche as ascii strings”. (again, read the thread, the whole thread.) The problem is i don’t think it’s as politically attractive as the current proposal, which is a long-negotiated compromise between a lot of different groups of people with different goals for single quoted literals. in fact someone suggested a v similar idea pretty early in the process except they were trying to cast multichar ascii literals to integer slugs instead of String. in fact if you go back to the upper part of the thread it’s a lot closer to the original pitch than the current proposal. I don’t see anything wrong with option 5. Character with a capital C is the abstraction we want to be capturing with the new single quoted literal. I actually argued for your approach myself further up the thread calling them "code point literals" when they were not limited to ASCII as it improved diagnostics but eventually saw the light and changed my mind. These are secondary internal distinctions which can be used to gate a new shorthand which allows us to express an integer with a character value but the requirements of the niche shorthand shouldn’t feedback to the definition of what is a character literal. ![]() Some of these Characters can be represented by a single unicode scalar, some of those fit int an integer storage implied by the expression context and some of those are ASCII. I like Swift’s highly principled abstraction that a Character is a single atomic visual entity regards of how it is represented and for me this is what we should be trying to encapsulate with single quote syntax. I’m sorry but I really don’t see how we should be elevating a legacy concept such as ASCII to such a prominent role in Swift. Just when I thought the thread was settling…. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |