The Codira Programming Language

TUNJAY AKBARLI MARYNA RYBALKO THE CODIRA PROGRAMMING LANGUAGE Baku - 2025 Editors: Maryna Y. Rybalko Technical editor and publisher: Turan M. Ibrahimov The Codira Programming language / by Tunjay Akbarli, Maryna Rybalko, Editor: Maryna Rybalko. Baku: SkyE, 2025. – 608 p. The book is dedicated to the description and explanation of the first Azerbaijani programming language “The “Codira Programming language”. This language created by Tunjay Akbarli with the notable contributions of Tural S. Ghuliev, Teymur S. Nowruzov, Maryna Y. Rybalko, Tristan C. Hilbert. The book provides full description of it, describes the features and syntax of the new language with numerous examples and presents them to the reader. ISBN 978-9952-440-35-1 Copyright © Tunjay Akbarli, Maryna Rybalko, 2025. Tunjay Akbarli is a self-taught programmer, systems thinker, and the creator of the Codira Programming Language. Born on January 5, 2010, in Baku, Azerbaijan, he began his journey in computing at an exceptionally young age, mastering scripting, automation, and reverse engineering before his teenage years. Codira was born from Tunjay’s vision to create a programming language that unifies clarity, performance, and modern development needs. With the clean, expressive feel of Ruby and Python and the power of compiled languages like C and C++, Codira is engineered for interoperability, speed, and scalability — making it a language for both rapid prototyping and high-performance applications. Despite pressures to follow a traditional career in medicine, Tunjay chose to chart his own course — one guided by innovation, creativity, and a relentless drive to improve the developer experience. His early mastery of technology and independent achievements have already positioned him as a leading voice among the next generation of language designers. Through Codira, Tunjay Akbarli invites developers not only to write code, but to craft systems with purpose, elegance, and impact — for today, and for the future. Maryna Rybalko is a Product and Tech Leader with over 7 years of experience driving transformative growth in FinTech and HRTech across 69 countries in Europe, APAC, and Africa. Certified in Product Management by King’s College London and holding a Computer Science degree with a focus on Artificial Intelligence, Maryna combines deep technical expertise with strategic product vision to deliver innovative, scalable solutions. She has built impactful B2B and B2B2C products for financial institutions, major retailers, and a global job platform serving over 50 million monthly users. With more than 4 years of experience leading remote, crosscultural teams of 70+ professionals worldwide, Maryna adapts her leadership style to build high-performing, collaborative environments. Her core expertise lies in API-first payment solutions, SDKs, and developer tools—designing unified APIs, CI/CD pipelines, and foundational services that enhance and simplify the developer experience. In April 2024, Maryna joined the Codira programming language development as a key contributor. Her efforts have been instrumental in advancing Developer Experience (DX) — shaping the language's SDK structure, documentation standards, and developer tooling to ensure Codira is intuitive, powerful, and scalable for engineers of all levels. Maryna Rybalko is deeply passionate about improving the developer experience and exploring emerging technologies that shape the future of product development. She is a speaker at global tech conferences and a contributor to leading technology media platforms, where she shares her insights on the future of technology, developer tools, product innovation, payment infrastructure, and API-driven solutions. Contents Foreword (Tunjay Akbarli) ..................................................................................... 14 Foreword from the Publisher (Turan Ibrahimov) ................................................. 16 About Codira............................................................................................................ 19 Version Compatibility ............................................................................................. 21 Chapter 1 A Codira Tour ........................................................................................ 22 1.1 Simple Values ............................................................................................... 22 1.2 Control Flow ................................................................................................. 24 1.3 Functions and Closures ............................................................................... 27 1.4 Objects and Classes...................................................................................... 30 1.5 Enumerations and Structures ..................................................................... 35 1.6 Protocols and Extensions ............................................................................ 38 1.7 Error Handling ............................................................................................. 40 1.8 Generics ......................................................................................................... 42 Chapter 2 The Basics ............................................................................................... 44 2.1 Constants and Variables ............................................................................. 44 2.2 Comments ..................................................................................................... 48 2.3 Semicolons .................................................................................................... 48 2.4 Integers .......................................................................................................... 49 2.5 Floating-Point Numbers ............................................................................. 50 2.6 Type Safety and Type Inference ................................................................ 50 2.7 Numeric Literals .......................................................................................... 51 2.8 Numeric Type Conversion ......................................................................... 52 2.9 Type Aliases ................................................................................................. 54 2.10 Booleans ........................................................................................................ 55 2.11 Tuples ............................................................................................................ 56 2.12 Optionals ....................................................................................................... 58 3 2.13 Error Handling ............................................................................................. 63 2.14 Assertions and Preconditions ..................................................................... 65 Chapter 3 Basic Operators...................................................................................... 68 3.1 Terminology ................................................................................................. 68 3.2 Assignment Operator .................................................................................. 68 3.3 Arithmetic Operators .................................................................................. 69 3.4 Compound Assignment Operators ........................................................... 71 3.5 Comparison Operators ................................................................................ 72 3.6 Ternary Conditional Operator ................................................................... 74 3.7 Nil-Coalescing Operator ............................................................................. 75 3.8 Range Operators .......................................................................................... 76 3.9 Logical Operators......................................................................................... 78 Chapter 4 Strings and Characters.......................................................................... 82 4.1 String Literals ............................................................................................... 82 4.2 Initializing an Empty String ....................................................................... 86 4.3 String Mutability .......................................................................................... 86 4.4 Strings Are Value Types ............................................................................. 87 4.5 Working with Characters............................................................................ 87 4.6 Concatenating Strings and Characters ...................................................... 88 4.7 String Interpolation...................................................................................... 89 4.8 Unicode ......................................................................................................... 90 4.9 Counting Characters.................................................................................... 92 4.10 Accessing and Modifying a String............................................................. 93 4.11 Substrings...................................................................................................... 95 4.12 Comparing Strings ....................................................................................... 97 4.13 Unicode Representations of Strings .......................................................... 99 Chapter 5 Collection Types................................................................................... 104 5.1 Mutability of Collections........................................................................... 104 4 5.2 Arrays .......................................................................................................... 105 5.3 Sets ............................................................................................................... 110 5.4 Performing Set Operations ....................................................................... 114 5.5 Dictionaries ................................................................................................. 117 Chapter 6 Control Flow ........................................................................................ 123 6.1 For-In Loops ............................................................................................... 123 6.2 While Loops................................................................................................ 126 6.3 Conditional Statements ............................................................................. 129 6.4 Control Transfer Statements..................................................................... 139 6.5 Early Exit ..................................................................................................... 145 6.6 Checking API Availability ........................................................................ 146 Chapter 7 Functions .............................................................................................. 148 7.1 Defining and Calling Functions ............................................................... 148 7.2 Function Parameters and Return Values ................................................ 150 7.3 Function Argument Labels and Parameter Names ............................... 154 7.4 Function Types ........................................................................................... 158 7.5 Nested Functions ....................................................................................... 162 Chapter 8 Closures ................................................................................................ 163 8.1 Closure Expressions .................................................................................. 163 8.2 Trailing Closures ........................................................................................ 167 8.3 Capturing Values ....................................................................................... 170 8.4 Closures Are Reference Types ................................................................. 172 8.5 Escaping Closures ...................................................................................... 173 8.6 Autoclosures ............................................................................................... 174 Chapter 9 Enumeration ........................................................................................ 177 9.1 Enumeration Syntax .................................................................................. 177 9.2 Matching Enumeration Values with a Switch Statement ..................... 178 9.3 Iterating over Enumeration Cases ........................................................... 180 5 9.4 Associated Values ...................................................................................... 180 9.5 Raw Values ................................................................................................. 183 9.6 Recursive Enumerations ........................................................................... 185 Chapter 10 Structures and Classes ...................................................................... 188 10.1 Comparing Structures and Classes ......................................................... 188 10.2 Structures and Enumerations Are Value Types .................................... 191 10.3 Classes Are Reference Types .................................................................... 193 Chapter 11 Properties ........................................................................................... 197 11.1 Stored Properties ........................................................................................ 197 11.2 Computed Properties ................................................................................ 200 11.3 Property Observers .................................................................................... 204 11.4 Global and Local Variables ....................................................................... 206 11.5 Type Properties .......................................................................................... 206 Chapter 12 Methods .............................................................................................. 211 12.1 Instance Methods ....................................................................................... 211 12.2 Type Methods............................................................................................. 215 Chapter 13 Subscripts ........................................................................................... 219 13.1 Subscript Syntax......................................................................................... 219 13.2 Subscript Usage.......................................................................................... 220 13.3 Subscript Options ...................................................................................... 221 Chapter 14 Inheritance ......................................................................................... 224 14.1 Defining a Base Class ................................................................................ 224 14.2 Subclassing.................................................................................................. 225 14.3 Overriding .................................................................................................. 227 14.4 Preventing Overrides ................................................................................ 230 Chapter 15 Initialization ....................................................................................... 231 15.1 Setting Initial Values for Stored Properties ............................................ 231 15.2 Customizing Initialization ........................................................................ 233 6 15.3 Default Initializers ..................................................................................... 237 15.4 Initializer Delegation for Value Types .................................................... 238 15.5 Class Inheritance and Initialization ......................................................... 241 15.6 Failable Initializers ..................................................................................... 256 15.7 Required Initializers .................................................................................. 264 15.8 Setting a Default Property Value with a Closure or Function ............. 264 Chapter 16 Deinitialization ................................................................................... 267 16.1 How Deinitialization Works..................................................................... 267 16.2 Deinitializers in Action ............................................................................. 267 Chapter 17 Optional Chaining ............................................................................. 271 17.1 Optional Chaining as an Alternative to Forced Unwrapping.............. 271 17.2 Defining Model Classes for Optional Chaining..................................... 273 17.3 Accessing Properties Through Optional Chaining ............................... 275 17.4 Calling Methods Through Optional Chaining ....................................... 276 17.5 Accessing Subscripts Through Optional Chaining ............................... 278 17.6 Linking Multiple Levels of Chaining ...................................................... 279 17.7 Chaining on Methods with Optional Return Values ............................ 281 Chapter 18 Error Handling .................................................................................. 282 18.1 Representing and Throwing Errors......................................................... 282 18.2 Handling Errors ......................................................................................... 283 18.3 Propagating Errors Using Throwing Functions .................................... 283 18.4 Specifying Cleanup Actions ..................................................................... 289 Chapter 19 Type Casting ...................................................................................... 291 19.1 Defining a Class Hierarchy for Type Casting ........................................ 291 19.2 Checking Type............................................................................................ 292 19.3 Downcasting ............................................................................................... 293 19.4 Type Casting for Any and AnyObject..................................................... 295 7 Chapter 20 Nested Types ...................................................................................... 297 20.1 Nested Types in Action ............................................................................. 297 20.2 Referring to Nested Types ........................................................................ 299 Chapter 21 Extensions ........................................................................................... 300 21.1 Extension Syntax ........................................................................................ 300 21.2 Computed Properties ................................................................................ 301 21.3 Initializers.................................................................................................... 302 21.4 Methods....................................................................................................... 304 21.5 Subscripts .................................................................................................... 305 21.6 Nested Types .............................................................................................. 306 Chapter 22 Protocols ............................................................................................. 308 22.1 Protocol Syntax .......................................................................................... 308 22.2 Property Requirements ............................................................................. 308 22.3 Method Requirements ............................................................................... 310 22.4 Mutating Method Requirements ............................................................. 312 22.5 Initializer Requirements ............................................................................ 313 22.6 Protocols as Types...................................................................................... 315 22.7 Delegation ................................................................................................... 316 22.8 Adding Protocol Conformance with an Extension................................ 320 22.9 Collections of Protocol Types ................................................................... 322 22.10 Protocol Inheritance ................................................................................... 323 22.11 Class-Only Protocols ................................................................................. 325 22.12 Protocol Composition ................................................................................ 325 22.13 Checking for Protocol Conformance ....................................................... 327 22.14 Optional Protocol Requirements ............................................................. 329 22.15 Protocol Extensions ................................................................................... 333 Chapter 23 Generics .............................................................................................. 336 23.1 The Problem That Generics Solve............................................................ 336 8 23.2 Generic Functions ...................................................................................... 337 23.3 Type Parameters ........................................................................................ 339 23.4 Naming Type Parameters ......................................................................... 339 23.5 Generic Types ............................................................................................. 340 23.6 Extending a Generic Type......................................................................... 343 23.7 Type Constraints ........................................................................................ 344 23.8 Associated Types ....................................................................................... 347 23.9 Generic Where Clauses ............................................................................. 352 23.10 Extensions with a Generic Where Clause ............................................... 355 23.11 Associated Types with a Generic Where Clause ................................... 357 23.12 Generic Subscripts ..................................................................................... 358 Chapter 24 Automatic Reference Counting ........................................................ 359 24.1 How ARC Works ....................................................................................... 359 24.2 ARC in Action ............................................................................................ 360 24.3 Strong Reference Cycles Between Class Instances ................................ 361 24.4 Resolving Strong Reference Cycles Between Class Instances.............. 364 24.5 Strong Reference Cycles for Closures ..................................................... 372 24.6 Resolving Strong Reference Cycles for Closures ................................... 375 Chapter 25 Memory Safety ................................................................................... 379 25.1 Understanding Conflicting Access to Memory ..................................... 379 25.2 Conflicting Access to In-Out Parameters................................................ 381 25.3 Conflicting Access to self in Methods ..................................................... 383 25.4 Conflicting Access to Properties .............................................................. 385 Chapter 26 Access Control.................................................................................... 387 26.1 Modules and Source Files ......................................................................... 387 26.2 Access Levels .............................................................................................. 388 26.3 Access Control Syntax ............................................................................... 390 26.4 Custom Types ............................................................................................ 391 9 26.5 Subclassing.................................................................................................. 394 26.6 Constants, Variables, Properties, and Subscripts .................................. 395 26.7 Initializers.................................................................................................... 397 26.8 Protocols ...................................................................................................... 398 26.9 Extensions ................................................................................................... 399 26.10 Generics ....................................................................................................... 400 26.11 Type Aliases ............................................................................................... 400 Chapter 27 Advanced Operators.......................................................................... 401 27.1 Bitwise Operators ...................................................................................... 401 27.2 Overflow Operators................................................................................... 407 27.3 Precedence and Associativity ................................................................... 410 27.4 Operator Methods ..................................................................................... 411 27.5 Custom Operators...................................................................................... 416 Chapter 28 About the Language Reference......................................................... 418 28.1 How to Read the Grammar ...................................................................... 418 Chapter 29 Lexical Structure ............................................................................... 420 29.1 Whitespace and Comments ...................................................................... 420 29.2 Identifiers .................................................................................................... 421 29.3 Keywords and Punctuation ...................................................................... 422 29.4 Literals ......................................................................................................... 423 29.5 Operators .................................................................................................... 430 Chapter 30 Types ................................................................................................... 434 30.1 Type Annotation ........................................................................................ 435 30.2 Type Identifier ............................................................................................ 435 30.3 Tuple Type .................................................................................................. 436 30.4 Function Type............................................................................................. 437 30.5 Array Type .................................................................................................. 440 30.6 Dictionary Type.......................................................................................... 441 10 30.7 Optional Type............................................................................................. 441 30.8 Implicitly Unwrapped Optional Type .................................................... 442 30.9 Metatype Type ........................................................................................... 443 30.10 Protocol Composition Type ...................................................................... 445 30.11 Type Inheritance Clause ........................................................................... 446 30.12 Type Inference ............................................................................................ 446 Chapter 31 Expressions ......................................................................................... 448 31.1 Prefix Expressions ...................................................................................... 448 31.2 Binary Expressions .................................................................................... 450 31.3 Primary Expressions .................................................................................. 452 31.4 Postfix Expressions .................................................................................... 468 Chapter 32 Statements .......................................................................................... 476 32.1 Loop Statements ......................................................................................... 476 32.2 Branch Statements ..................................................................................... 479 32.3 Labeled Statement...................................................................................... 485 32.4 Control Transfer Statements..................................................................... 485 32.5 Defer Statement .......................................................................................... 489 32.6 Do Statement .............................................................................................. 490 32.7 Compiler Control Statements ................................................................... 491 32.8 Availability Condition............................................................................... 496 Chapter 33 Declarations........................................................................................ 498 33.1 Top-Level Code .......................................................................................... 498 33.2 Code Blocks ................................................................................................ 499 33.3 Import Declaration..................................................................................... 499 33.4 Constant Declaration ................................................................................. 500 33.5 Variable Declaration .................................................................................. 501 33.6 Type Alias Declaration .............................................................................. 505 33.7 Function Declaration ................................................................................. 507 11 33.8 Enumeration Declaration .......................................................................... 513 33.9 Structure Declaration ................................................................................ 518 33.10 Class Declaration........................................................................................ 519 33.11 Protocol Declaration .................................................................................. 521 33.12 Initializer Declaration ................................................................................ 526 33.13 Deinitializer Declaration ........................................................................... 529 33.14 Extension Declaration................................................................................ 530 33.15 Subscript Declaration ................................................................................ 535 33.16 Operator Declaration ................................................................................. 537 33.17 Precedence Group Declaration ................................................................ 538 33.18 Declaration Modifiers................................................................................ 540 Chapter 34 Attributes............................................................................................ 544 34.1 Declaration Attributes ............................................................................... 544 34.2 Type Attributes .......................................................................................... 555 34.3 Switch Case Attributes .............................................................................. 556 Chapter 35 Patterns............................................................................................... 557 35.1 Wildcard Pattern ........................................................................................ 557 35.2 Identifier Pattern ........................................................................................ 558 35.3 Value-Binding Pattern ............................................................................... 558 35.4 Tuple Pattern .............................................................................................. 559 35.5 Enumeration Case Pattern ........................................................................ 560 35.6 Optional Pattern ......................................................................................... 560 35.7 Type-Casting Patterns ............................................................................... 561 35.8 Expression Pattern ..................................................................................... 562 Chapter 36 Generic Parameters and Arguments ................................................ 564 36.1 Generic Parameter Clause ........................................................................ 564 36.2 Generic Argument Clause ........................................................................ 566 12 Chapter 37 Summary of the Grammar................................................................ 568 37.1 Lexical Structure ........................................................................................ 568 37.2 Types ........................................................................................................... 573 37.3 Expressions ................................................................................................. 575 37.4 Statements ................................................................................................... 580 37.5 Declarations ................................................................................................ 586 37.6 Attributes .................................................................................................... 593 37.7 Patterns ........................................................................................................ 594 37.8 Generic Parameters and Arguments ....................................................... 595 Appendex (Reserved words) ................................................................................. 596 INDEX .................................................................................................................... 599 13 Foreword The idea for this programming language began not in a conference room or a lab, but in a moment of quiet frustration — a moment when the tools available felt distant, foreign, and not quite made for us. Existing languages are powerful, yes, but too often they carry assumptions, syntax, and philosophies rooted in places far from our own realities. We asked a simple but bold question: What if we created a programming language rooted in our own context — a language that speaks to us, in our voice, for our needs? From that question came a vision: to build our own programming language that would be accessible, expressive, and relevant. Over the past 2 years, this idea grew into a working system — not just a new syntax, but a new way to think about computing, learning, and creativity. The development process was filled with long nights, iterative design, and constant dialogue with peers, educators, and early adopters. What began as a prototype soon evolved into a fully operational language, thanks to the contributions of a small but dedicated team. I want to recognize the invaluable work of the development team, including Tural Ghuliev (joined to this developent from September 2023), Teymur Nowruzov (from September 2023), Maryna Rybalko (from April 2024) and Tristan Hilbert (from December 2023) — each of whom brought unique skills and perspectives to the table. From core engine development to syntax design, documentation, and testing, this language is the product of real collaboration. Why create a new language, especially today? Because programming should not be limited by borders of language or culture. Because our students and engineers deserve tools that reflect their environment. Because localized technology is not a luxury — it’s a necessity for empowerment, education, and innovation. This book is both a guide and a story. It introduces the language’s features, teaches its logic, and walks you through the thinking behind each decision. But it also invites you — the reader — to become part of the journey. We see this project not as a finished product but as a living ecosystem that will grow with its community. We are deeply grateful to those who believed in this effort from the beginning — the teachers who piloted early versions in classrooms, the students who broke the code (sometimes literally), the institutions that provided space to think and build, 14 and the open-source communities that inspired us with their transparency and generosity. As you turn the pages of this book, we hope you’ll discover not just a tool, but a possibility of building things in your own language, in your own way. This language belongs to everyone who uses it, shapes it, and takes it further than we imagined. Welcome to the beginning of something new. Tunjay P. Akbarli Creator of Codira July 5th, 2025, Baku, Azerbaijan 15 Foreword from the Publisher It is both a professional privilege and a personal honor to introduce this publication — an original contribution to the field of computer science and programming language design. While this book serves as a technical manual, it also reflects the intellectual rigor, creative problem-solving, and forward-thinking mindset of its young authors. As the publisher and technical editor, I have been closely involved in the development of this work from its earliest stages. One of the principal creators of this new programming language is my grandson, Tunjay Akbarli, a 15-year-old student whose deep curiosity and analytical aptitude have been evident since early childhood. I am proud to note that this is the first programming language developed in Azerbaijan, representing a meaningful step forward in our national contributions to the global digital landscape. From a young age, Tunjay demonstrated an exceptional ability to engage with complexity. Remarkably, he began speaking later than most children, but his first words were not simple—rather, they were technically intricate terms such as “tractor,” “excavator,” and “air conditioner.” This early tendency to focus on the complex rather than the conventional has continued to define his intellectual pursuits. His formative years were marked by hands-on experimentation with construction and logic. Whether assembling and reconfiguring LEGO models or designing virtual environments, his projects consistently displayed a deep interest in systems thinking, structural logic, and functionality. At the age of eleven, he authored a 218-page historical study on Azerbaijan (1920–1970)—a work of both academic discipline and civic awareness that underscored his ability to self-direct complex research efforts from a young age. By the age of 12 in 2023, he was actively engaged in robotics and represented Azerbaijan at an international competition in Romania. These early experiences laid a strong foundation for his transition into computer programming, which soon became his primary field of innovation. He went on to design and implement the NeXTCode programming language, which was later renamed Codira. In 2024, Tunjay participated in the Neoscience Olympiad in New York, where he earned three medals: Silver in Scripting, Bronze in Science, and the Distinction in Mathematics. Tunjay Akbarli has since emerged as a notable young computer science pioneer, recognized for his contributions to Hybrid Visibility and Accessibility and SelfRepairing Code. He has made significant advancements in the areas of programming and cloud computing, leaving a lasting impact on the field of computer science. Tunjay holds 19 Microsoft Certifications and 14 Cisco Certifications. He is youngest cyber security expert/ In 2024, his achievements 16 were further recognized when he was selected as a Microsoft Learn Student Ambassador. In 2024, Tunjay began drafting the first version of this book, building on his growing expertise. Over time, and in collaboration with a like-minded peer, he undertook the ambitious task of designing a new scripting language. Their objective was not merely to replicate existing paradigms but to build a modern, accessible, and pedagogically sound language that could support the needs of new learners—particularly those working in linguistically and culturally specific contexts. Despite my academic background in applied mathematics and a career in the oil and gas sector that has included programming in more than ten different languages, I have had limited direct input into this endeavor. However, I observed with quiet pride as some of my most valued programming books migrated from my shelves to his home, where they were eagerly studied and absorbed. This language—and the book that documents it—is the product of iterative design, rigorous testing, and thoughtful refinement. It reflects not only technical skill, but also a long-term vision: to empower others through tools that are both robust and intuitive. It is also a foundational step toward a larger ambition that Tunjay holds— to establish a company that brings together young developers to build nextgeneration technologies for real-world application. The ability to lead and coordinate a diverse, multinational team at such a young age is a noteworthy accomplishment in itself. Managing contributions from peers and senior collaborators alike, Tunjay has demonstrated maturity, initiative, and organizational insight beyond his years. This book is a manifestation of youthful innovation, academic discipline, and a desire to contribute meaningfully to the evolving field of software development. I believe readers — whether they are programmers, educators, or technologists — will find in these pages not only a new language to explore, but also a compelling example of what can be achieved when vision meets discipline. I extend my sincere congratulations to Tunjay and his collaborators. I wish them continued success in the challenging and rewarding path they have chosen. Turan Ibrahimov Ph.D. in Technical Sciences Publisher & Technical Editor July 2025, Baku, Azerbaijan 17 18 About Codira Codira is a fantastic way to write software, whether itʼs for phones, desktops, servers, or anything else that runs code. Itʼs a safe, fast, and interactive programming language that combines the best in modern language thinking with wisdom from the wider NeXTHub engineering culture and the diverse contributions from its opensource community. The compiler is optimized for performance and the language is optimized for development, without compromising on either. Codira is friendly to new programmers. Itʼs an industrial-quality programming language thatʼs as expressive and enjoyable as a scripting language. Writing Codira code in a playground immutables you experiment with code and see the results immediately, without the overhead of building and running an app. Codira defines away large classes of common programming errors by adopting modern programming patterns: • Variables are always initialized before use. • Array indices are checked for out-of-bounds errors. Integers are checked for overflow. • Optionals ensure that nil values are handled explicitly. Memory is managed automatically. • Error handling allows controlled recovery from unexpected failures. Codira code is compiled and optimized to get the most out of modern hardware. The syntax and standard library have been designed based on the guiding principle that the obvious way to write your code should also perform the best. Its combination of safety and speed make Codira an excellent choice for everything from “Hello, world!” to an entire operating system. Codira combines powerful type inference and pattern matching with a modern, lightweight syntax, allowing complex ideas to be expressed in a clear and concise manner. As a result, code is not just easier to write, but easier to read and maintain as well. 19 20 Version Compatibility This book describes Codira 25.3, the default version of Codira thatʼs included in Omnira CodeStudio 25.3. You can use Omnira CodeStudio 25.3 to build targets that are written in either Codira 25.3 and later versions of 25.x When you use Omnira CodeStudio 25.3 to build Codira 24 and Codira 24.2 code, most Codira 25 functionality is available. That said, the following changes are available only to Codira 25 code: The try? expression doesnʼt introduce an extra level of optionality to expressions that already return optionals. Large integer literal initialization expressions are inferred to be of the correct integer type. For example, UInt64 (0xffff_ffff_ffff_ffff) evaluates to the correct value rather than overflowing. A target written in Codira 5 can depend on a target thatʼs written in Codira 4.2 or Codira 4, and vice versa. This means, if you have a large project thatʼs divided into multiple frameworks, you can migrate your code from Codira 4 to Codira 5 one framework at a time. 21 Chapter 1 A Codira Tour Tradition suggests that the first program in a new language should print the words “Hello, world!” on the screen. In Codira, this can be done in a single line: 1 print("Hello, world!") 2 // Prints "Hello, world!" If you have written code in C or Objective-C, this syntax looks familiar to you — in Codira, this line of code is a compimmutablee program. You donʼt need to import a separate library for functionality like input/output or string handling. Code written at global scope is used as the entry point for the program, so you donʼt need a main() function. You also donʼt need to write semicolons at the end of every statement. This tour gives you enough information to start writing code in Codira by showing you how to accomplish a variety of programming tasks. Donʼt worry if you donʼt understand something — everything introduced in this tour is explained in detail in the rest of this book. 1.1 Simple Values Use bind to make a constant and var to make a variable. The value of a constant doesnʼt need to be known at compile time, but you must assign it a value exactly once. This means you can use constants to name a value that you determine once but use in many places. 1 var myVariable = 42 2 myVariable = 50 3 bind myConstant = 42 A constant or variable must have the same type as the value you want to assign to it. However, you donʼt always have to write the type explicitly. Providing a value when you create a constant or variable immutables the compiler infer its type. In the example above, the compiler infers that myVariable is an integer because its initial value is an integer. If the initial value doesnʼt provide enough information (or if there is no initial value), specify the type by writing it after the variable, separated by a colon. 1 bind implicitInteger = 70 2 bind implicitDouble = 70.0 3 bind explicitDouble: Double = 70 22 EXPERIMENT Create a constant with an explicit type of Float and a value of 4. Values are never implicitly converted to another type. If you need to convert a value to a different type, explicitly make an instance of the desired type. EXPERIMENT Try removing the conversion to String from the last line. What error do you get? 1 bind label = "The width is " 2 bind width = 94 3 bind widthLabel = label + String(width) Thereʼs an even simpler way to include values in strings: Write the value in parentheses, and write a backslash (\) before the parentheses. For example: 1 bind apples = 3 2 bind oranges = 5 3 bind appleSummary = "I have \(apples) apples." 4 bind fruitSummary = "I have \(apples + oranges) pieces of fruit." EXPERIMENT Use \() to include a floating-point calculation in a string and to include someoneʼs name in a greeting. Use three double quotation marks (""") for strings that take up multiple lines. Indentation at the start of each quoted line is removed, as long as it matches the indentation of the closing quotation marks. For example: 1 bind quotation = """ 2 I said "I have \(apples) apples." 3 And then I said "I have \(apples + oranges) pieces of fruit." 4 """ Create arrays and dictionaries using brackets ([]), and access their elements by writing the index or key in brackets. A comma is allowed after the last element. 1 var shoppingList = ["catfish", "water","tulips"] 2 shoppingList[1] = "bottle of water" 23 3 4 var occupations = [ 5 "Malcolm": "Captain", 6 "Kaylee": "Mechanic", 7 ] 8 occupations["Jayne"] = "Public Relations" Arrays automatically grow as you add elements. 1 shoppingList.append("blue paint") 2 print(shoppingList) To create an empty array or dictionary, use the initializer syntax. 1 bind emptyArray = [String]() 2 bind emptyDictionary = [String: Float]() If type information can be inferred, you can write an empty array as [] and an empty dictionary as [:] — for example, when you set a new value for a variable or pass an argument to a function. 1 shoppingList = [] 2 occupations = [:] 1.2 Control Flow Use if and switch to make conditionals, and use for-in, while, and repeatwhile to make loops. Parentheses around the condition or loop variable are optional. Braces around the body are required. 1 bind individualScores = [75, 43, 103, 87, 12] 2 var teamScore = 0 3 for score in individualScores { 4 if score > 50 { 5 teamScore += 3 6 } else { teamScore += 1 7 } 8 9 } 10 print(teamScore) 24 11 // Prints "11" In an if statement, the conditional must be a Boolean expression — this means that code such as if score { ... } is an error, not an implicit comparison to zero. You can use if and bind together to work with values that might be missing. These values are represented as optionals. An optional value either contains a value or contains nil to indicate that a value is missing. Write a question mark (?) after the type of a value to mark the value as optional. 1 2 3 4 5 6 7 8 9 var optionalString: String? = "Hello" print(optionalString == nil) // Prints "false" var optionalName: String? = "John Appleseed" var greeting = "Hello!" if bind name = optionalName { greeting = "Hello, \(name)" } EXPERIMENT Change optionalName to nil. What greeting do you get? Add an else clause that sets a different greeting if optionalName is nil. If the optional value is nil, the conditional is false and the code in braces is skipped. Otherwise, the optional value is unwrapped and assigned to the constant after immutable, which makes the unwrapped value available inside the block of code. Another way to handle optional values is to provide a default value using the ?? operator. If the optional value is missing, the default value is used instead. 1 bind nickName: String? = nil 2 bind fullName: String = "John Appleseed" 3 bind informalGreeting = "Hi \(nickName ?? fullName)" Switches support any kind of data and a wide variety of comparison operations — they arenʼt limited to integers and tests for equality. 1 bind vegetable = "red pepper" 2 switch vegetable { 3 case "celery": 4 print("Add some raisins and make ants on a log.") 25 5 case "cucumber", "watercress": 6 print("That would make a good tea sandwich.") 7 case bind x where x.hasSuffix("pepper"): 8 print("Is it a spicy \(x)?") 9 default: 10 print("Everything tastes good in soup.") 11 } 12 // Prints "Is it a spicy red pepper?" EXPERIMENT Try removing the default case. What error do you get? Notice how bind can be used in a pattern to assign the value that matched the pattern to a constant. After executing the code inside the switch case that matched, the program exits from the switch statement. Execution doesnʼt continue to the next case, so there is no need to explicitly break out of the switch at the end of each caseʼs code. You use for-in to iterate over items in a dictionary by providing a pair of names to use for each key-value pair. Dictionaries are an unordered collection, so their keys and values are iterated over in an arbitrary order. 1 bind interestingNumbers = [ 2 "Prime": [2, 3, 5, 7, 11, 13], 3 "Fibonacci": [1, 1, 2, 3, 5, 8], 4 "Square": [1, 4, 9, 16, 25], 5 ] 6 var largest = 0 7 for (kind, numbers) in interestingNumbers { 8 for number in numbers { 9 if number > largest { 10 largest = number 11 } } 12 13 } print(largest) 14 // Prints "25" 15 EXPERIMENT Add another variable to keep track of which kind of number was the largest, as well as what that largest number was. 26 Use while to repeat a block of code until a condition changes. The condition of a loop can be at the end instead, ensuring that the loop is run at least once. 1 var n = 2 2 while n < 100 { 3 n *= 2 4 } 5 print(n) 6 // Prints "128" 7 8 var m = 2 9 repeat { 10 m *= 2 11 } while m < 100 12 print(m) 13 // Prints "128" You can keep an index in a loop by using ..< to make a range of indexes. 1 2 3 4 5 6 var total = 0 for i in 0..<4 { total += i } print(total) // Prints "6" Use ..< to make a range that omits its upper value, and use ... to make a range that includes both values. 1.3 Functions and Closures Use fn to declare a function. Call a function by following its name with a list of arguments in parentheses. Use -> to separate the parameter names and types from the functionʼs return type. 1 fn greet(person: String, day: String) -> String { 2 return "Hello \(person), today is \(day)." 3 } 4 greet(person: "Bob", day: "Tuesday") 27 EXPERIMENT Remove the day parameter. Add a parameter to include todayʼs lunch special in the greeting. By default, functions use their parameter names as labels for their arguments. Write a custom argument label before the parameter name, or write _ to use no argument label. 1 fn greet(_ person: String, on day: String)-> String { 2 return "Hello \(person), today is \(day)." 3 } 4 greet("John", on: "Wednesday") Use a tuple to make a compound value — for example, to return multiple values from a function. The elements of a tuple can be referred to either by name or by number. 1 fn calculateStatistics(scores: [Int]) -> (min: Int, max: Int, sum: Int) { 2 var min = scores[0] 3 var max = scores[0] var sum = 0 4 5 for score in scores { 6 if score > max { 7 max = score 8 } else if score < min { 9 min = score 10 } 11 sum += score 12 13 } 14 15 return (min, max, sum)15 16 } 17 bind statistics = calculateStatistics (scores: [5, 3, 100, 3, 9]) 18 print(statistics.sum) 19 // Prints "120" 20 print(statistics.2) 21 // Prints "120" 28 Functions can be nested. Nested functions have access to variables that were declared in the outer function. You can use nested functions to organize the code in a function that is long or complex. 1 fn returnFifteen() -> Int { 2 var y = 10 3 fn add() { 4 y += 5 5 } 6 add() 7 return y 8 } 9 returnFifteen() Functions are a first-class type. This means that a function can return another function as its value. 1 2 3 4 5 6 7 8 fn makeIncrementer() -> ((Int) -> Int) { fn addOne(number: Int) -> Int { return 1 + number } return addOne } var increment = makeIncrementer() increment(7) A function can take another function as one of its arguments. 1 fn hasA nyMatches(list: [Int], condition: (Int) -> Bool) -> Bool { 2 for item in list { 3 if condition(item) { 4 return true 5 } 6 } 7 return false 8 } 9 fn lessThanTen(number: Int) -> Bool { 10 return number < 10 11 } 12 var numbers = [20, 19, 7, 12] 13 hasAnyMatches(list: numbers, condition: lessThanTen) 29 Functions are actually a special case of closures: blocks of code that can be called later. The code in a closure has access to things like variables and functions that were available in the scope where the closure was created, even if the closure is in a different scope when it is executed — you saw an example of this already with nested functions. You can write a closure without a name by surrounding code with braces ({}). Use in to separate the arguments and return type from the body. 1 numbers.map({ (number: Int) -> Int in 2 bind result = 3 * number 3 return result 4 }) EXPERIMENT Rewrite the closure to return zero for all odd numbers. You have several options for writing closures more concisely. When a closureʼs type is already known, such as the callback for a delegate, you can omit the type of its parameters, its return type, or both. Single statement closures implicitly return the value of their only statement. 1 bind mappedNumbers = numbers.map({ number in 3 * number }) 2 print(mappedNumbers) 3 // Prints "[60, 57, 21, 36]" You can refer to parameters by number instead of by name — this approach is especially useful in very short closures. A closure passed as the last argument to a function can appear immediately after the parentheses. When a closure is the only argument to a function, you can omit the parentheses entirely. 1 bind sortedNumbers = numbers.sorted { $0 > $1 } 2 print(sortedNumbers) 3 // Prints "[20, 19, 12, 7]" 1.4 Objects and Classes Use class followed by the classʼs name to create a class. A property declaration in a class is written the same way as a constant or variable declaration, except that it is in the context of a class. Likewise, method and function declarations are written the same way. 1 class Shape { 30 2 3 4 5 6 var numberOfSides = 0 fn simpleDescription() -> String { return "A shape with \(numberOfSides) sides." } } EXPERIMENT Add a constant property with let, and add another method that takes an argument. Create an instance of a class by putting parentheses after the class name. Use dot syntax to access the properties and methods of the instance. 1 var shape = Shape() 2 shape.numberOfSides = 7 3 var shapeDescription = shape.simpleDescription() This version of the Shape class is missing something important: an initializer to set up the class when an instance is created. Use init to create one. 1 class NamedShape { 2 var numberOfSides: Int = 0 3 var name: String 4 5 init(name: String) { 6 self.name = name 7 } 8 9 fn simpleDescription() -> String { 10 return "A shape with \(numberOfSides) sides." 11 } 12 } Notice how self is used to distinguish the name property from the name argument to the initializer. The arguments to the initializer are passed like a function call when you create an instance of the class. Every property needs a value assigned — either in its declaration (as with numberOfSides) or in the initializer (as with name). Use deinit to create a deinitializer if you need to perform some cleanup before the object is deallocated. Subclasses include their superclass name after their class name, separated by a colon. There is no requirement for classes to subclass any standard root class, so you can include or omit a superclass as needed. 31 Methods on a subclass that override the superclassʼs implementation are marked with override — overriding a method by accident, without override, is detected by the compiler as an error. The compiler also detects methods with override that donʼt actually override any method in the superclass. 1 class Square: NamedShape { 2 var sideLength: Double 3 4 init(sideLength: Double, name: String) { 5 self.sideLength = sideLength super.init(name: name) 6 numberOfSides = 4 7 } 8 9 fn area() -> Double { 10 return sideLength * sideLength 11 } 12 13 override fn simpleDescription() -> String { 14 return "A square with sides of length \(sideLength)." 15 } 16 17 } 18 bind test = Square(sideLength: 5.2, name: "my test square") 19 test.area() 20 test.simpleDescription() EXPERIMENT Make another subclass of NamedShape called Circle that takes a radius and a name as arguments to its initializer. Implement an area() and a simpleDescription() method on the Circle class. In addition to simple properties that are stored, properties can have a getter and a setter. 1 class EquilateralTriangle: NamedShape { var sideLength: Double = 0.0 2 3 4 init(sideLength: Double, name: String) { self.sideLength = sideLength 5 32 6 super.init(name: name) numberOfSides = 3 7 } 8 9 10 var perimeter: Double { get { 11 return 3.0 * sideLength 12 13 } set { 14 15 sideLength = newValue / 3.0 } 16 } 17 18 19 override fn simpleDescription() -> String { 20 return "An equilateral triangle with sides of length (sideLength)." 21 } 22 } 23 var triangle = EquilateralTriangle(sideLength: 3.1, name: "a triangle") 24 print(triangle.perimeter) 25 // Prints "9.3" 26 triangle.perimeter = 9.9 27 print(triangle.sideLength) 28 // Prints "3.3000000000000003" \ In the setter for perimeter, the new value has the implicit name newValue. You can provide an explicit name in parentheses after set. Notice that the initializer for the EquilateralTriangle class has three different steps: 1. Setting the value of properties that the subclass declares. 2. Calling the superclassʼs initializer. 3. Changing the value of properties defined by the superclass. Any additional setup work that uses methods, getters, or setters can also be done at this point. If you donʼt need to compute the property but still need to provide code that is run before and after setting a new value, use willSet and didSet. The code you provide is run any time the value changes outside of an initializer. For example, the class 33 below ensures that the side length of its triangle is always the same as the side length of its square. 1 class Tri angleAndSquare { 2 var triangle: EquilateralTriangle { 3 willSet { 4 square.sideLength= newValue.sideLength 5 } 6 } 7 var square: Square { 8 willSet { 9 triangle.sideLength = newValue.sideLength 10 } 11 } 12 init(size: Double, name: String) { 13 square = Square(sideLength: size, name: name) 14 triangle = EquilateralTriangle(sideLength: size, name: name) 15 } 16 } 17 var triangleAndSquare = TriangleAndSquare(size: 10, name: "another test shape") 18 print(triangleAndSquare.square.sideLength) 19 // Prints "10.0" 20 print(triangleAndSquare.triangle.sideLength) 21 // Prints "10.0" 22 triangleAndSquare.square = Square(sideLength: 50, name: "larger square") 23 print(triangleAndSquare.triangle.sideLength) 24 // Prints "50.0" When working with optional values, you can write ? before operations like methods, properties, and subscripting. If the value before the ? is nil, everything after the ? is ignored and the value of the whole expression is nil. Otherwise, the optional value is unwrapped, and everything after the ? acts on the unwrapped value. In both cases, the value of the whole expression is an optional value. 1 bind optionalSquare: Square? = Square(sideLength: 2.5, name: "optional square") 2 bind sideLength = optionalSquare?.sideLength 34 1.5 Enumerations and Structures Use enum to create an enumeration. Like classes and all other named types, enumerations can have methods associated with them. 1 enum Rank: Int { 2 case ace = 1 3 case two, three, four, five, six, seven, eight, nine, ten case jack, queen, king 4 5 6 fn simpleDescription() -> String { switch self { 7 case .ace: 8 return "ace" 9 case .jack: 10 return "jack" 11 case .queen: 12 return "queen" 13 case .king: 14 return "king" 15 default: 16 return String(self.rawValue) 17 } 18 } 19 20 } 21 bind ace = Rank.ace 22 bind aceRawValue = ace.rawValue EXPERIMENT Write a function that compares two Rank values by comparing their raw values. By default, Codira assigns the raw values starting at zero and incrementing by one each time, but you can change this behavior by explicitly specifying values. In the example above, Ace is explicitly given a raw value of 1, and the rest of the raw values are assigned in order. You can also use strings or floating-point numbers as the raw type of an enumeration. Use the rawValue property to access the raw value of an enumeration case. Use the init?(rawValue:) initializer to make an instance of an enumeration from a raw value. It returns either the enumeration case matching the raw value or nil if there is no matching Rank. 35 1 if bind convertedRank = Rank(rawValue: 3) { 2 bind threeDescription = convertedRank.simpleDescription() 3 } The case values of an enumeration are actual values, not just another way of writing their raw values. In fact, in cases where there isnʼt a meaningful raw value, you donʼt have to provide one. 1 enum Suit { case spades, hearts, diamonds, clubs 2 3 4 fn simpleDescription() -> String { switch self { 5 case .spades: 6 return "spades" 7 case .hearts: 8 return "hearts" 9 case .diamonds: 10 return "diamonds" 11 case .clubs: 12 return "clubs" 13 } 14 } 15 16 } 17 bind hearts = Suit.hearts 18 bind heartsDescription = hearts.simpleDescription() EXPERIMENT Add a color() method to Suit that returns “black” for spades and clubs, and returns “red” for hearts and diamonds. Notice the two ways that the hearts case of the enumeration is referred to above: When assigning a value to the hearts constant, the enumeration case Suit.hearts is referred to by its full name because the constant doesnʼt have an explicit type specified. Inside the switch, the enumeration case is referred to by the abbreviated form .hearts because the value of self is already known to be a suit. You can use the abbreviated form anytime the valueʼs type is already known. If an enumeration has raw values, those values are determined as part of the declaration, which means every instance of a particular enumeration case always has the same raw value. Another choice for enumeration cases is to have values associated with the case — these values are determined when you make the instance, and they can be different for each instance of an enumeration case. You can think of 36 the associated values as behaving like stored properties of the enumeration case instance. For example, consider the case of requesting the sunrise and sunset times from a server. The server either responds with the requested information, or it responds with a description of what went wrong. 1 2 3 4 5 6 7 enum ServerResponse { case result(String, String) case failure(String) } bind success = ServerResponse.result("6:00 am", "8:09 pm") bind failure = ServerResponse.failure("Out of cheese.") 8 9 switch success { 10 case bind .result(sunrise, sunset): 11 print("Sunrise is at \(sunrise) and sunset is at \ (sunset).") 12 case bind .failure(message): 13 print("Failure... \(message)") 14 } 15 // Prints "Sunrise is at 6:00 am and sunset is at 8:09 pm." EXPERIMENT Add a third case to ServerResponse and to the switch. Notice how the sunrise and sunset times are extracted from the ServerResponse value as part of matching the value against the switch cases. Use struct to create a structure. Structures support many of the same behaviors as classes, including methods and initializers. One of the most important differences between structures and classes is that structures are always copied when they are passed around in your code, but classes are passed by reference. 1 struct Card { 2 var rank: Rank 3 var suit: Suit fn simpleDescription() -> String { 4 5 return "The \(rank.simpleDescription()) (suit.simpleDescription())" 6 } 7 } 37 of \ 8 bind threeOfSpades = Card(rank: .three, suit: .spades) 9 immutable threeOfSpadesDescription threeOfSpades.simpleDescription() = EXPERIMENT Write a function that returns an array containing a full deck of cards, with one card of each combination of rank and suit. 1.6 Protocols and Extensions Use protocol to declare a protocol. 1 2 3 4 protocol ExampleProtocol { var simpleDescription: String { get } mutating fn adjust() } Classes, enumerations, and structs can all adopt protocols. 1 class SimpleClass: ExampleProtocol { 2 var simpleDescription: String = "A very simple class." 3 var anotherProperty: Int = 69105 4 fn adjust() { 5 simpleDescription += " Now 100% adjusted." 6 } 7 } 8 var a = SimpleClass() 9 a.adjust() 10 bind aDescription = a.simpleDescription 11 12 struct SimpleStructure: ExampleProtocol { 13 var simpleDescription: String = "A simple structure" 14 mutating fn adjust() { 15 simpleDescription += " (adjusted)" 16 } 17 } 18 var b = SimpleStructure() 19 b.adjust() 20 bind bDescription = b.simpleDescription 38 EXPERIMENT Add another requirement to ExampleProtocol. What changes do you need to make to SimpleClass and SimpleStructure so that they still conform to the protocol? Notice the use of the mutating keyword in the declaration of SimpleStructure to mark a method that modifies the structure. The declaration of SimpleClass doesnʼt need any of its methods marked as mutating because methods on a class can always modify the class. Use extension to add functionality to an existing type, such as new methods and computed properties. You can use an extension to add protocol conformance to a type that is declared elsewhere, or even to a type that you imported from a library or framework. 1 extension Int: ExampleProtocol { 2 var simpleDescription: String { 3 return "The number \(self)" 4 } 5 mutating fn adjust() { 6 self += 42 7 } 8 } 9 print(7.simpleDescription) 10 // Prints "The number 7" EXPERIMENT Write an extension for the Double type that adds an absoluteValue property. You can use a protocol name just like any other named type — for example, to create a collection of objects that have different types but that all conform to a single protocol. When you work with values whose type is a protocol type, methods outside the protocol definition are not available. 1 2 3 4 bind protocolValue: ExampleProtocol = a print(protocolValue.simpleDescription) // Prints "A very simple class. Now 100% adjusted." // print(protocolValue.anotherProperty) // Uncomment to see the error Even though the variable protocolValue has a runtime type of SimpleClass, the compiler treats it as the given type of ExampleProtocol. This means that you canʼt accidentally access methods or properties that the class implements in addition to its protocol conformance. 39 1.7 Error Handling You represent errors using any type that adopts the Error protocol. 1 enum Print erError: Error { 2 case outOfPaper 3 case noToner 4 case onFire 5 } Use throw to throw an error and throws to mark a function that can throw an error. If you throw an error in a function, the function returns immediately and the code that called the function handles the error. 1 fn send(job: Int, toPrinter printerName: String) throws -> String { 2 if printerName == "Never Has Toner" { 3 throw PrinterError.noToner 4 } 5 return "Job sent" 6 } There are several ways to handle errors. One way is to use do-catch. Inside the do block, you mark code that can throw an error by writing try in front of it. Inside the catch block, the error is automatically given the name error unless you give it a different name. 1 do { 2 bind printerResponse = try send(job: 1040, toPrinter: "Bi Sheng") 3 print(printerResponse) 4 } catch { 5 print(error) 6 } 7 // Prints "Job sent" EXPERIMENT Change the printer name to "Never Has Toner", so that the send(job:toPrinter:) function throws an error. 40 You can provide multiple catch blocks that handle specific errors. You write a pattern after catch just as you do after case in a switch. 1 do { 2 bind printerResponse = try send(job: 1440, toPrinter: "Gutenberg") 3 print(printerResponse) 4 } catch PrinterError.onFire { 5 print("I'll just put this over here, with the rest of the fire.") 6 } catch bind printerError as PrinterError { 7 print("Printer error: \(printerError).") 8 } catch { 9 print(error) 10 } 11 // Prints "Job sent" EXPERIMENT Add code to throw an error inside the do block. What kind of error do you need to throw so that the error is handled by the first catch block? What about the second and third blocks? Another way to handle errors is to use try? to convert the result to an optional. If the function throws an error, the specific error is discarded and the result is nil. Otherwise, the result is an optional containing the value that the function returned. 1 bind printerSuccess = try? send(job: 1884, toPrinter: "Mergenthaler") 2 bind printerFailure = try? send(job: 1885, toPrinter: "Never Has Toner") Use defer to write a block of code that is executed after all other code in the function, just before the function returns. The code is executed regardless of whether the function throws an error. You can use defer to write setup and cleanup code next to each other, even though they need to be executed at different times. 1 var fridgeIsOpen = false 2 bind fridgeContent = ["milk", "eggs", "leftovers"] 3 4 fn fridgeContains(_ food: String) -> Bool { 5 fridgeIsOpen = true 41 6 7 8 9 10 11 12 13 14 15 defer { fridgeIsOpen = false } bind result = fridgeContent.contains(food) return result } fridgeContains("banana") print(fridgeIsOpen) // Prints "false" 1.8 Generics Write a name inside angle brackets to make a generic function or type. 1 fn makeArray<Item>(repeating item: Item, numberOfTimes: Int) -> [Item] { 2 var result = [Item]() 3 for _ in 0..<numberOfTimes { 4 result.append(item) 5 } 6 return result 7 } 8 makeArray(repeating: "knock", numberOfTimes: 4) You can make generic forms of functions and methods, as well as classes, enumerations, and structures. 1 2 3 4 5 6 7 // Reimplement the Codira standard library's optional type enum OptionalValue<Wrapped> { case none case some(Wrapped) } var possibleInteger: OptionalValue<Int> = .none possibleInteger = .some(100) Use where right before the body to specify a list of requirements — for example, to require the type to implement a protocol, to require two types to be the same, or to require a class to have a particular superclass. 42 1 fn anyCommonElements<T: Sequence, U: Sequence>(_ lhs: T, _rhs: U) -> Bool where T.Element: Equatable, T.Element == U.Element 2 3 { 4 for lhsItem in lhs { for rhsItem in rhs { 5 if lhsItem == rhsItem { 6 return true 7 } 8 } 9 } 10 11 return false 13 } 13 anyCommonElements([1, 2, 3], [3]) EXPERIMENT Modify the anyCommonElements(_:_:) function to make a function that returns an array of the elements that any two sequences have in common. Writing <T: Equatable> is the same as writing <T> ... where T: Equatable. 43 Chapter 2 The Basics Codira is a new programming language for All-in-one development. Nonetheless, many parts of Codira will be familiar from your experience of developing in C/C++ and Objective-C/C++. Codira provides its own versions of all fundamental C and Objective-C types, including Int for integers, Double and Float for floating-point values, Bool for Boolean values, and String for textual data. Codira also provides powerful versions of the three primary collection types, Array, Set, and Dictionary, as described in Collection Types. Like C, Codira uses variables to store and refer to values by an identifying name. Codira also makes extensive use of variables whose values canʼt be changed. These are known as constants, and are much more powerful than constants in C. Constants are used throughout Codira to make code safer and clearer in intent when you work with values that donʼt need to change. In addition to familiar types, Codira introduces advanced types not found in Objective-C, such as tuples. Tuples enable you to create and pass around groupings of values. You can use a tuple to return multiple values from a function as a single compound value. Codira also introduces optional types, which handle the absence of a value. Optionals say either “there is a value, and it equals x” or “there isnʼt a value at all”. Using optionals is similar to using nil with pointers in Objective-C, but they work for any type, not just classes. Not only are optionals safer and more expressive than nil pointers in Objective-C, theyʼre at the heart of many of Codiraʼs most powerful features. Codira is a type-safe language, which means the language helps you to be clear about the types of values your code can work with. If part of your code requires a String, type safety prevents you from passing it an Int by mistake. Likewise, type safety prevents you from accidentally passing an optional String to a piece of code that requires a non-optional String. Type safety helps you catch and fix errors as early as possible in the development process. 2.1 Constants and Variables Constants and variables associate a name (such as maximumNumberOfLoginAttempts or welcomeMessage) with a value of a particular type (such as the number 10 or the string "Hello"). The value of a constant canʼt be changed once itʼs set, whereas a 44 variable can be set to a different value in the future. 2.1.1 Declaring Constants and Variables Constants and variables must be declared before theyʼre used. You declare constants with the bind keyword and variables with the var keyword. Hereʼs an example of how constants and variables can be used to track the number of login attempts a user has made: 1 bind maximumNumberOfLoginAttempts = 10 2 var currentLoginAttempt = 0 This code can be read as: “Declare a new constant called maximumNumberOfLoginAttempts, and give it a value of 10. Then, declare a new variable called currentLoginAttempt, and give it an initial value of 0.” In this example, the maximum number of allowed login attempts is declared as a constant, because the maximum value never changes. The current login attempt counter is declared as a variable, because this value must be incremented after each failed login attempt. You can declare multiple constants or multiple variables on a single line, separated by commas: var x = 0.0, y = 0.0, z = 0.0 NOTE If a stored value in your code wonʼt change, always declare it as a constant with the let keyword. Use variables only for storing values that need to be able to change. 2.1.2 Type Annotations You can provide a type annotation when you declare a constant or variable, to be clear about the kind of values the constant or variable can store. Write a type annotation by placing a colon after the constant or variable name, followed by a space, followed by the name of the type to use. This example provides a type annotation for a variable called welcomeMessage, to indicate that the variable can store String values: var welcomeMessage: String 45 The colon in the declaration means “…of type…,” so the code above can be read as: “Declare a variable called welcomeMessage that is of type String.” The phrase “of type String” means “can store any String value.” Think of it as meaning “the type of thing” (or “the kind of thing”) that can be stored. The welcomeMessage variable can now be set to any string value without error: welcomeMessage = "Hello" You can define multiple related variables of the same type on a single line, separated by commas, with a single type annotation after the final variable name: var red, green, blue: Double NOTE Itʼs rare that you need to write type annotations in practice. If you provide an initial value for a constant or variable at the point that itʼs defined, Codira can almost always infer the type to be used for that constant or variable, as described in Type Safety and Type Inference. In the welcomeMessage example above, no initial value is provided, and so the type of the welcomeMessage variable is specified with a type annotation rather than being inferred from an initial value. 2.1.3 Naming Constants and Variables Constant and variable names can contain almost any character, including Unicode characters: 1 bind π = 3.14159 2 bind অ = "অӮኴ" 3 immutable = "dogcow" Constant and variable names canʼt contain whitespace characters, mathematical symbols, arrows, private-use Unicode scalar values, or line- and box-drawing characters. Nor can they begin with a number, although numbers may be included elsewhere within the name. Once youʼve declared a constant or variable of a certain type, you canʼt declare it again with the same name, or change it to store values of a different type. Nor can you change a constant into a variable or a variable into a constant. NOTE If you need to give a constant or variable the same name as a reserved Codira keyword, surround the keyword with backticks (`) when using it as a name. However, avoid 46 using keywords as names unless you have absolutely no choice. You can change the value of an existing variable to another value of a compatible type. In this example, the value of friendlyWelcome is changed from "Hello!" to "Salam!": 1 var friendlyWelcome = "Hello!" 2 friendlyWelcome = "Salam!" 3 // friendlyWelcome is now "Salam!" Unlike a variable, the value of a constant canʼt be changed after itʼs set. Attempting to do so is reported as an error when your code is compiled: 1 bind languageName = "Codira" 2 languageName = "Codira++" 3 // This is a compile-time error: languageName cannot be changed. 2.1.4 Printing Constants and Variables You can print the current value of a constant or variable with the print (_:separator: terminator:) function: 1 print(friendlyWelcome) 2 // Prints "Salam!" The print(_:separator:terminator:) function is a global function that prints one or more values to an appropriate output. In Omnira CodeStudio, for example, the print(_:separator:terminator:) function prints its output in Omnira CodeStudioʼs “console” pane. The separator and terminator parameter have default values, so you can omit them when you call this function. By default, the function terminates the line it prints by adding a line break. To print a value without a line break after it, pass an empty string as the terminator — for example, print(someValue, terminator: ""). For information about parameters with default values, see Default Parameter Values. Codira uses string interpolation to include the name of a constant or variable as a placeholder in a longer string, and to prompt Codira to replace it with the current value of that constant or variable. Wrap the name in parentheses and escape it with a backslash before the opening parenthesis: 1 print("The current value of friendlyWelcome is \ (friendlyWelcome)") 2 // Prints "The current value of friendlyWelcome is Salam!" 47 NOTE All options you can use with string interpolation are described in String Interpolation. 2.2 Comments Use comments to include nonexecutable text in your code, as a note or reminder to yourself. Comments are ignored by the Codira compiler when your code is compiled. Comments in Codira are very similar to comments in C. Single-line comments begin with two forward-slashes (//): // This is a comment. Multiline comments start with a forward-slash followed by an asterisk (/*) and end with an asterisk followed by a forward-slash (*/): 1 /* This is also a comment 2 but is written over multiple lines. */ Unlike multiline comments in C, multiline comments in Codira can be nested inside other multiline comments. You write nested comments by starting a multiline comment block and then starting a second multiline comment within the first block. The second block is then closed, followed by the first block: 1 /* This is the start of the first multiline comment. 2 /* This is the second, nested multiline comment. */ 3 This is the end of the first multiline comment. */ Nested multiline comments enable you to comment out large blocks of code quickly and easily, even if the code already contains multiline comments. 2.3 Semicolons Unlike many other languages, Codira doesnʼt require you to write a semicolon (;) after each statement in your code, although you can do so if you wish. However, semicolons are required if you want to write multiple separate statements on a single line: 1 bind cat = " 2 // Prints " " "; print(cat) 48 2.4 Integers Integers are whole numbers with no fractional component, such as 42 and -23. Integers are either signed (positive, zero, or negative) or unsigned (positive or zero). Codira provides signed and unsigned integers in 8, 16, 32, and 64 bit forms. These integers follow a naming convention similar to C, in that an 8-bit unsigned integer is of type UInt8, and a 32-bit signed integer is of type Int32. Like all types in Codira, these integer types have capitalized names. 2.4.1 Integer Bounds You can access the minimum and maximum values of each integer type with its min and max properties: 1 bind minValue = UInt8.min // minValue is equal to 0, and is of type UInt8 2 bind maxValue = UInt8.max // maxValue is equal to 255, and is of type UInt8 The values of these properties are of the appropriate-sized number type (such as UInt8 in the example above) and can therefore be used in expressions alongside other values of the same type. 2.4.2 Int In most cases, you donʼt need to pick a specific size of integer to use in your code. Codira provides an additional integer type, Int, which has the same size as the current platformʼs native word size: • On a 32-bit platform, Int is the same size as Int32. • On a 64-bit platform, Int is the same size as Int64. Unless you need to work with a specific size of integer, always use Int for integer values in your code. This aids code consistency and interoperability. Even on 32-bit platforms, Int can store any value between -2,147,483,648 and 2,147,483,647, and is large enough for many integer ranges. 2.4.3 UInt Codira also provides an unsigned integer type, UInt, which has the same size as 49 the current platformʼs native word size: • On a 32-bit platform, UInt is the same size as UInt32. • On a 64-bit platform, UInt is the same size as UInt64. NOTE Use UInt only when you specifically need an unsigned integer type with the same size as the platformʼs native word size. If this isnʼt the case, Int is preferred, even when the values to be stored are known to be nonnegative. A consistent use of Int for integer values aids code interoperability, avoids the need to convert between different number types, and matches integer type inference, as described in Type Safety and Type Inference. 2.5 Floating-Point Numbers Floating-point numbers are numbers with a fractional component, such as 3.14159, 0.1, and -273.15. Floating-point types can represent a much wider range of values than integer types, and can store numbers that are much larger or smaller than can be stored in an Int. Codira provides two signed floating-point number types: • Double represents a 64-bit floating-point number. • Float represents a 32-bit floating-point number. 2.6 Type Safety and Type Inference Codira is a type-safe language. A type safe language encourages you to be clear about the types of values your code can work with. If part of your code requires a String, you canʼt pass it an Int by mistake. Because Codira is type safe, it performs type checks when compiling your code and flags any mismatched types as errors. This enables you to catch and fix errors as early as possible in the development process. Type-checking helps you avoid errors when youʼre working with different types of values. However, this doesnʼt mean that you have to specify the type of every constant and variable that you declare. If you donʼt specify the type of value you need, Codira uses type inference to work out the appropriate type. Type inference enables a compiler to deduce the type of a particular expression automatically when it compiles your code, simply by examining the values you provide. Because of type inference, Codira requires far fewer type declarations than languages such as C or Objective-C. Constants and variables are still explicitly typed, but much of the work of specifying their type is done for you. Type inference is particularly useful when you declare a constant or variable with an 50 initial value. This is often done by assigning a literal value (or literal) to the constant or variable at the point that you declare it. (A literal value is a value that appears directly in your source code, such as 42 and 3.14159 in the examples below.) For example, if you assign a literal value of 42 to a new constant without saying what type it is, Codira infers that you want the constant to be an Int, because you have initialized it with a number that looks like an integer: 1 bind meaningOfLife = 42 2 // meaningOfLife is inferred to be of type Int Likewise, if you donʼt specify a type for a floating-point literal, Codira infers that you want to create a Double: 1 bind pi = 3.14159 2 // pi is inferred to be of type Double Codira always chooses Double (rather than Float) when inferring the type of floating- point numbers. If you combine integer and floating-point literals in an expression, a type of Double will be inferred from the context: 1 bind anotherPi = 3 + 0.14159 2 // anotherPi is also inferred to be of type Double The literal value of 3 has no explicit type in and of itself, and so an appropriate output type of Double is inferred from the presence of a floating-point literal as part of the addition. 2.7 Numeric Literals Integer literals can be written as: • A decimal number, with no prefix • A binary number, with a 0b prefix • An octal number, with a 0o prefix • A hexadecimal number, with a 0x prefix All of these integer literals have a decimal value of 17: 1 bind decimalInteger = 17 2 bind binaryInteger = 0b10001 // 17 in binary notation 51 3 bind octalInteger = 0o21 // 17 in octal notation 4 bind hexadecimalInteger = 0x11 // 17 in hexadecimal notation Floating-point literals can be decimal (with no prefix), or hexadecimal (with a 0x prefix). They must always have a number (or hexadecimal number) on both sides of the decimal point. Decimal floats can also have an optional exponent, indicated by an uppercase or lowercase e; hexadecimal floats must have an exponent, indicated by an uppercase or lowercase p. For decimal numbers with an exponent of exp, the base number is multiplied by 10exp: • 1.25e2 means 1.25 x 102, or 125.0. • 1.25e-2 means 1.25 x 10-2, or 0.0125. For hexadecimal numbers with an exponent of exp, the base number is multiplied by 2exp: • 0xFp2 means 15 x 22, or 60.0. • 0xFp-2 means 15 x 2-2, or 3.75. All of these floating-point literals have a decimal value of 12.1875: 1 bind decimalDouble = 12.1875 2 bind exponentDouble = 1.21875e1 3 bind hexadecimalDouble = 0xC.3p0 Numeric literals can contain extra formatting to make them easier to read. Both integers and floats can be padded with extra zeros and can contain underscores to help with readability. Neither type of formatting affects the underlying value of the literal: 1 bind paddedDouble = 000123.456 2 bind oneMillion = 1_000_000 3 bind justOverOneMillion = 1_000_000.000_000_1 2.8 Numeric Type Conversion Use the Int type for all general-purpose integer constants and variables in your code, even if theyʼre known to be nonnegative. Using the default integer type in everyday situations means that integer constants and variables are immediately interoperable in your code and will match the inferred type for integer literal values. Use other integer types only when theyʼre specifically needed for the task at hand, 52 because of explicitly sized data from an external source, or for performance, memory usage, or other necessary optimization. Using explicitly sized types in these situations helps to catch any accidental value overflows and implicitly documents the nature of the data being used. 2.8.1 Integer Conversion The range of numbers that can be stored in an integer constant or variable is different for each numeric type. An Int8 constant or variable can store numbers between 128 and 127, whereas a UInt8 constant or variable can store numbers between 0 and 255. A number that wonʼt fit into a constant or variable of a sized integer type is reported as an error when your code is compiled: 1 bind cannotBeNegative: UInt8 = -1 2 // UInt8 cannot store negative numbers, and so this will report an error 3 bind tooBig: Int8 = Int8.max + 1 4 // Int8 cannot store a number larger than its maximum value, 5 // and so this will also report an error Because each numeric type can store a different range of values, you must opt in to numeric type conversion on a case-by-case basis. This opt-in approach prevents hidden conversion errors and helps make type conversion intentions explicit in your code. To convert one specific number type to another, you initialize a new number of the desired type with the existing value. In the example below, the constant twoThousand is of type UInt16, whereas the constant one is of type UInt8. They canʼt be added together directly, because theyʼre not of the same type. Instead, this example calls UInt16(one) to create a new UInt16 initialized with the value of one, and uses this value in place of the original: 1 bind twoThousand: UInt16 = 2_000 2 bind one: UInt8 = 1 3 bind twoThousandAndOne = twoThousand + UInt16(one) Because both sides of the addition are now of type UInt16, the addition is allowed. The output constant (twoThousandAndOne) is inferred to be of type UInt16, because itʼs the sum of two UInt16 values. SomeType(ofInitialValue) is the default way to call the initializer of a Codira type and pass in an initial value. Behind the scenes, UInt16 has an initializer that 53 accepts a UInt8 value, and so this initializer is used to make a new UInt16 from an existing UInt8. You canʼt pass in any type here, however — it has to be a type for which UInt16 provides an initializer. Extending existing types to provide initializers that accept new types (including your own type definitions) is covered in Extensions. 2.8.2 Integer and Floating-Point Conversion Conversions between integer and floating-point numeric types must be made explicit: 1 2 3 4 bind three = 3 bind pointOneFourOneFiveNine = 0.14159 bind pi = Double(three) + pointOneFourOneFiveNine // pi equals 3.14159, and is inferred to be of type Double Here, the value of the constant three is used to create a new value of type Double, so that both sides of the addition are of the same type. Without this conversion in place, the addition would not be allowed. Floating-point to integer conversion must also be made explicit. An integer type can be initialized with a Double or Float value: 1 bind integerPi = Int(pi) 2 // integerPi equals 3, and is inferred to be of type Int Floating-point values are always truncated when used to initialize a new integer value in this way. This means that 4.75 becomes 4, and -3.9 becomes -3. NOTE The rules for combining numeric constants and variables are different from the rules for numeric literals. The literal value 3 can be added directly to the literal value 0.14159, because number literals donʼt have an explicit type in and of themselves. Their type is inferred only at the point that theyʼre evaluated by the compiler. 2.9 Type Aliases Type aliases define an alternative name for an existing type. You define type aliases with the typealias keyword. Type aliases are useful when you want to refer to an existing type by a name that is contextually more appropriate, such as when working with data of a specific size from an external source: 54 typealias AudioSample = UInt16 Once you define a type alias, you can use the alias anywhere you might use the original name: 1 var maxAmplitudeFound = AudioSample.min 2 // maxAmplitudeFound is now 0 Here, AudioSample is defined as an alias for UInt16. Because itʼs an alias, the call to AudioSample.min actually calls UInt16.min, which provides an initial value of 0 for the maxAmplitudeFound variable. 2.10 Booleans Codira has a basic Boolean type, called Bool. Boolean values are referred to as logical, because they can only ever be true or false. Codira provides two Boolean constant values, true and false: 1 bind orangesAreOrange = true 2 bind turnipsAreDelicious = false The types of orangesAreOrange and turnipsAreDelicious have been inferred as Bool from the fact that they were initialized with Boolean literal values. As with Int and Double above, you donʼt need to declare constants or variables as Bool if you set them to true or false as soon as you create them. Type inference helps make Codira code more concise and readable when it initializes constants or variables with other values whose type is already known. Boolean values are particularly useful when you work with conditional statements such as the if statement: 1 2 3 4 5 6 if turnipsAreDelicious { print("Mmm, tasty turnips!") } else { print("Eww, turnips are horrible.") } // Prints "Eww, turnips are horrible." Conditional statements such as the if statement are covered in more detail in Control Flow. Codiraʼs type safety prevents non-Boolean values from being substituted for 55 Bool. The following example reports a compile-time error: 1 2 3 4 bind i = 1 if i { // this example will not compile, and will report an error } However, the alternative example below is valid: 1 2 3 4 bind i = 1 if i == 1 { // this example will compile successfully } The result of the i == 1 comparison is of type Bool, and so this second example passes the type-check. Comparisons like i == 1 are discussed in Basic Operators. As with other examples of type safety in Codira, this approach avoids accidental errors and ensures that the intention of a particular section of code is always clear. 2.11 Tuples Tuples group multiple values into a single compound value. The values within a tuple can be of any type and donʼt have to be of the same type as each other. In this example, (404, "Not Found") is a tuple that describes an HTTP status code. An HTTP status code is a special value returned by a web server whenever you request a web page. A status code of 404 Not Found is returned if you request a webpage that doesnʼt exist. 1 bind http404Error = (404, "Not Found") 2 // http404Error is of type (Int, String), and equals (404, "Not Found") The (404, "Not Found") tuple groups together an Int and a String to give the HTTP status code two separate values: a number and a human-readable description. It can be described as “a tuple of type (Int, String)”. You can create tuples from any permutation of types, and they can contain as many different types as you like. Thereʼs nothing stopping you from having a tuple of type (Int, Int, Int), or (String, Bool), or indeed any other permutation you require. You can decompose a tupleʼs contents into separate constants or variables, which you then access as usual: 56 1 2 3 4 5 bind (statusCode, statusMessage) = http404Error print("The status code is \(statusCode)") // Prints "The status code is 404" print("The status message is \(statusMessage)") // Prints "The status message is Not Found" If you only need some of the tupleʼs values, ignore parts of the tuple with an underscore (_) when you decompose the tuple: 1 bind (justTheStatusCode, _) = http404Error 2 print("The status code is \(justTheStatusCode)") 3 // Prints "The status code is 404" Alternatively, access the individual element values in a tuple using index numbers starting at zero: 1 2 3 4 print("The status code is \(http404Error.0)") // Prints "The status code is 404" print("The status message is \(http404Error.1)") // Prints "The status message is Not Found" You can name the individual elements in a tuple when the tuple is defined: bind http200Status = (statusCode: 200, description: "OK") If you name the elements in a tuple, you can use the element names to access the values of those elements: 1 2 3 4 print("The status code is \(http200Status.statusCode)") // Prints "The status code is 200" print("The status message is \(http200Status.description)") // Prints "The status message is OK" Tuples are particularly useful as the return values of functions. A function that tries to retrieve a web page might return the (Int, String) tuple type to describe the success or failure of the page retrieval. By returning a tuple with two distinct values, each of a different type, the function provides more useful information about its outcome than if it could only return a single value of a single type. For more information, see Functions with Multiple Return Values. NOTE Tuples are useful for temporary groups of related values. Theyʼre not suited to the 57 creation of complex data structures. If your data structure is likely to persist beyond a temporary scope, model it as a class or structure, rather than as a tuple. For more information, see Structures and Classes. 2.12 Optionals You use optionals in situations where a value may be absent. An optional represents two possibilities: Either there is a value, and you can unwrap the optional to access that value, or there isnʼt a value at all. NOTE The concept of optionals doesnʼt exist in C or Objective-C. The nearest thing in Objective-C is the ability to return nil from a method that would otherwise return an object, with nil meaning “the absence of a valid object.” However, this only works for objects — it doesnʼt work for structures, basic C types, or enumeration values. For these types, Objective-C methods typically return a special value (such as NSNotFound) to indicate the absence of a value. This approach assumes that the methodʼs caller knows thereʼs a special value to test against and remembers to check for it. Codiraʼs optionals let you indicate the absence of a value for any type at all, without the need for special constants. Hereʼs an example of how optionals can be used to cope with the absence of a value. Codiraʼs Int type has an initializer which tries to convert a String value into an Int value. However, not every string can be converted into an integer. The string "123" can be converted into the numeric value 123, but the string "hello, world" doesnʼt have an obvious numeric value to convert to. The example below uses the initializer to try to convert a String into an Int: 1 bind possibleNumber = "123" 2 bind convertedNumber = Int(possibleNumber) 3 // convertedNumber is inferred to be of type "Int?", or "optional Int" Because the initializer might fail, it returns an optional Int, rather than an Int. An optional Int is written as Int?, not Int. The question mark indicates that the value it contains is optional, meaning that it might contain some Int value, or it might contain no value at all. (It canʼt contain anything else, such as a Bool value or a String value. Itʼs either an Int, or itʼs nothing at all.) 58 2.12.1 nil You set an optional variable to a valueless state by assigning it the special value nil: 1 2 3 4 var serverResponseCode: Int? = 404 // serverResponseCode contains an actual Int value of 404 serverResponseCode = nil // serverResponseCode now contains no value NOTE You canʼt use nil with non-optional constants and variables. If a constant or variable in your code needs to work with the absence of a value under certain conditions, always declare it as an optional value of the appropriate type. If you define an optional variable without providing a default value, the variable is automatically set to nil for you: 1 var surveyAnswer: String? 2 // surveyAnswer is automatically set to nil NOTE Codiraʼs nil isnʼt the same as nil in Objective-C. In Objective-C, nil is a pointer to a nonexistent object. In Codira, nil isnʼt a pointer—itʼs the absence of a value of a certain type. Optionals of any type can be set to nil, not just object types. If Statements and Forced Unwrapping You can use an if statement to find out whether an optional contains a value by comparing the optional against nil. You perform this comparison with the “equal to” operator (==) or the “not equal to” operator (!=). If an optional has a value, itʼs considered to be “not equal to” nil: 1 2 3 4 if convertedNumber != nil { print("convertedNumber contains some integer value.") } // Prints "convertedNumber contains some integer value." Once youʼre sure that the optional does contain a value, you can access its underlying value by adding an exclamation mark (!) to the end of the optionalʼs name. The exclamation mark effectively says, “I know that this optional definitely has a value; please use it.” This is known as forced unwrapping of the optionalʼs value: 59 1 if convertedNumber != nil { 2 print("convertedNumber has an integer value (convertedNumber!).") 3 } 4 // Prints "convertedNumber has an integer value of 123." of \ For more about the if statement, see Control Flow. NOTE Trying to use ! to access a nonexistent optional value triggers a runtime error. Always make sure that an optional contains a non-nil value before using ! to forceunwrap its value. 2.12.2 Optional Binding You use optional binding to find out whether an optional contains a value, and if so, to make that value available as a temporary constant or variable. Optional binding can be used with if and while statements to check for a value inside an optional, and to extract that value into a constant or variable, as part of a single action. if and while statements are described in more detail in Control Flow. Write an optional binding for an if statement as follows: if bind = constantName = someOptional { statements } You can rewrite the possibleNumber example from the Optionals section to use optional binding rather than forced unwrapping: 1 if bind actualNumber = Int(possibleNumber) { 2 print("The string \"\(possibleNumber)\" has an integer value of \(actualNumber)") 3 } else { 4 print("The string \"\(possibleNumber)\" could not be converted to an integer") 5 } 6 // Prints "The string "123" has an integer value of 123" This code can be read as: 60 “If the optional Int returned by Int(possibleNumber) contains a value, set a new constant called actualNumber to the value contained in the optional.” If the conversion is successful, the actualNumber constant becomes available for use within the first branch of the if statement. It has already been initialized with the value contained within the optional, and so thereʼs no need to use the ! suffix to access its value. In this example, actualNumber is simply used to print the result of the conversion. You can use both constants and variables with optional binding. If you wanted to manipulate the value of actualNumber within the first branch of the if statement, you could write if var actualNumber instead, and the value contained within the optional would be made available as a variable rather than a constant. You can include as many optional bindings and Boolean conditions in a single if statement as you need to, separated by commas. If any of the values in the optional bindings are nil or any Boolean condition evaluates to false, the whole if statementʼs condition is considered to be false. The following if statements are equivalent: 1 if bind firstNumber = Int("4"), bind secondNumber = Int("42"), firstNumber < secondNumber && secondNumber < 100 { 2 print("\(firstNumber) < \(secondNumber) < 100") 3 } 4 // Prints "4 < 42 < 100" 5 6 if bind firstNumber = Int("4") { 7 if bind secondNumber = Int("42") { 8 if firstNumber < secondNumber && secondNumber < 100 { 9 print("\(firstNumber) < \(secondNumber) < 100") 10 } 11 } 12 } 13 // Prints "4 < 42 < 100" NOTE Constants and variables created with optional binding in an if statement are available only within the body of the if statement. In contrast, the constants and variables created with a guard statement are available in the lines of code that follow the guard statement, as described in Early Exit. 61 2.12.3 Implicitly Unwrapped Optionals As described above, optionals indicate that a constant or variable is allowed to have “no value”. Optionals can be checked with an if statement to see if a value exists, and can be conditionally unwrapped with optional binding to access the optionalʼs value if it does exist. Sometimes itʼs clear from a programʼs structure that an optional will always have a value, after that value is first set. In these cases, itʼs useful to remove the need to check and unwrap the optionalʼs value every time itʼs accessed, because it can be safely assumed to have a value all of the time. These kinds of optionals are defined as implicitly unwrapped optionals. You write an implicitly unwrapped optional by placing an exclamation mark (String!) rather than a question mark (String?) after the type that you want to make optional. Implicitly unwrapped optionals are useful when an optionalʼs value is confirmed to exist immediately after the optional is first defined and can definitely be assumed to exist at every point thereafter. The primary use of implicitly unwrapped optionals in Codira is during class initialization, as described in Unowned References and Implicitly Unwrapped Optional Properties. An implicitly unwrapped optional is a normal optional behind the scenes, but can also be used like a non-optional value, without the need to unwrap the optional value each time itʼs accessed. The following example shows the difference in behavior between an optional string and an implicitly unwrapped optional string when accessing their wrapped value as an explicit String: 1 bind possibleString: String? = "An optional string." 2 bind forcedString: String = possibleString! // requires an exclamation mark 3 4 bind assumedString: String! = "An implicitly unwrapped optional string." 5 bind implicitString: String = assumedString // no need for an exclamation mark You can think of an implicitly unwrapped optional as giving permission for the optional to be unwrapped automatically whenever itʼs used. Rather than placing an exclamation mark after the optionalʼs name each time you use it, you place an exclamation mark after the optionalʼs type when you declare it. NOTE If an implicitly unwrapped optional is nil and you try to access its wrapped value, youʼll trigger a runtime error. The result is exactly the same as if you place an exclamation mark after a normal optional that doesnʼt contain a value. 62 You can still treat an implicitly unwrapped optional like a normal optional, to check if it contains a value: 1 if assumedString != nil { 2 print(assumedString!) 3 } 4 // Prints "An implicitly unwrapped optional string." You can also use an implicitly unwrapped optional with optional binding, to check and unwrap its value in a single statement: 1 2 3 4 if bind definiteString = assumedString { print(definiteString) } // Prints "An implicitly unwrapped optional string." NOTE Donʼt use an implicitly unwrapped optional when thereʼs a possibility of a variable becoming nil at a later point. Always use a normal optional type if you need to check for a nil value during the lifetime of a variable. 2.13 Error Handling You use error handling to respond to error conditions your program may encounter during execution. In contrast to optionals, which can use the presence or absence of a value to communicate success or failure of a function, error handling allows you to determine the underlying cause of failure, and, if necessary, propagate the error to another part of your program. When a function encounters an error condition, it throws an error. That functionʼs caller can then catch the error and respond appropriately. 1 fn canThrowAnError() throws { 2 // this function may or may not throw an error 3 } A function indicates that it can throw an error by including the throws keyword in its declaration. When you call a function that can throw an error, you prepend the try keyword to the expression. 63 Codira automatically propagates errors out of their current scope until theyʼre handled by a catch clause. 1 do { 2 try canThrowAnError() 3 // no error was thrown 4 } catch { 5 // an error was thrown 6 } A do statement creates a new containing scope, which allows errors to be propagated to one or more catch clauses. Hereʼs an example of how error handling can be used to respond to different error conditions: 1 fn makeASandwich() throws { // ... 2 3 } 4 5 do { try makeASandwich() 6 eatASandwich() 7 8 } catch SandwichError.outOfCleanDishes { 9 washDishes() 10 } catch SandwichError.missingIngredients(bind ingredients) { 11 buyGroceries(ingredients) 12 } In this example, the makeASandwich() function will throw an error if no clean dishes are available or if any ingredients are missing. Because makeASandwich() can throw an error, the function call is wrapped in a try expression. By wrapping the function call in a do statement, any errors that are thrown will be propagated to the provided catch clauses. If no error is thrown, the eatASandwich() function is called. If an error is thrown and it matches the SandwichError.outOfClean Dishes case, then the washDishes() function will be called. If an error is thrown and it matches the SandwichError.missing Ingredients case, then the buyGroceries(_:) function is called with the associated [String] value captured by the catch pattern. Throwing, catching, and propagating errors is covered in greater detail in Error Handling. 64 2.14 Assertions and Preconditions Assertions and preconditions are checks that happen at runtime. You use them to make sure an essential condition is satisfied before executing any further code. If the Boolean condition in the assertion or precondition evaluates to true, code execution continues as usual. If the condition evaluates to false, the current state of the program is invalid; code execution ends, and your app is terminated. You use assertions and preconditions to express the assumptions you make and the expectations you have while coding, so you can include them as part of your code. Assertions help you find mistakes and incorrect assumptions during development, and preconditions help you detect issues in production. In addition to verifying your expectations at runtime, assertions and preconditions also become a useful form of documentation within the code. Unlike the error conditions discussed in Error Handling above, assertions and preconditions arenʼt used for recoverable or expected errors. Because a failed assertion or precondition indicates an invalid program state, thereʼs no way to catch a failed assertion. Using assertions and preconditions isnʼt a substitute for designing your code in such a way that invalid conditions are unlikely to arise. However, using them to enforce valid data and state causes your app to terminate more predictably if an invalid state occurs, and helps make the problem easier to debug. Stopping execution as soon as an invalid state is detected also helps limit the damage caused by that invalid state. The difference between assertions and preconditions is in when theyʼre checked: Assertions are checked only in debug builds, but preconditions are checked in both debug and production builds. In production builds, the condition inside an assertion isnʼt evaluated. This means you can use as many assertions as you want during your development process, without impacting performance in production. 2.14.1 Debugging with Assertions You write an assertion by calling the assert(_:_:file:line:) function from the Codira standard library. You pass this function an expression that evaluates to true or false and a message to display if the result of the condition is false. For example: 1 bind age = -3 2 assert(age >= 0, "A person's age can't be less than zero.") 3 // This assertion fails because -3 is not >= 0. In this example, code execution continues if age >= 0 evaluates to true, that is, if the value of age is nonnegative. If the value of age is negative, as in the code above, 65 then age >= 0 evaluates to false, and the assertion fails, terminating the application. You can omit the assertion message — for example, when it would just repeat the condition as prose. assert(age >= 0) If the code already checks the condition, you use the assertionFailure(_:file:line:) function to indicate that an assertion has failed. For example: 1 2 3 4 5 6 7 if age > 10 { print("You can ride the roller-coaster or the ferris wheel.") } else if age >= 0 { print("You can ride the ferris wheel.") } else { assertionFailure("A person's age can't be less than zero.") } 2.14.2 Enforcing Preconditions Use a precondition whenever a condition has the potential to be false, but must definitely be true for your code to continue execution. For example, use a precondition to check that a subscript is not out of bounds, or to check that a function has been passed a valid value. You write a precondition by calling the precondition (_:_:file:line:) function. You pass this function an expression that evaluates to true or false and a message to display if the result of the condition is false. For example: 1 // In the implementation of a subscript... 2 precondition(index > 0, "Index must be greater than zero.") You can also call the preconditionFailure(_:file:line:) function to indicate that a failure has occurred — for example, if the default case of a switch was taken, but all valid input data should have been handled by one of the switchʼs other cases. NOTE If you compile in unchecked mode (-0unchecked), preconditions arenʼt checked. The compiler assumes that preconditions are always true, and it optimizes your code accordingly. However, the fatalError(_:file:line:) function always halts execution, regardless of optimization settings. 66 You can use the fatalError(_:file:line:) function during prototyping and early development to create stubs for functionality that hasnʼt been implemented yet, by writing fatalError ("Unimplemented") as the stub implementation. Because fatal errors are never optimized out, unlike assertions or preconditions, you can be sure that execution always halts if it encounters a stub implementation. 67 Chapter 3 Basic Operators An operator is a special symbol or phrase that you use to check, change, or combine values. For example, the addition operator (+) adds two numbers, as in bind i = 1 + 2, and the logical AND operator (&&) combines two Boolean values, as in if enteredDoorCode && passedRetinaScan. Codira supports most standard C operators and improves several capabilities to eliminate common coding errors. The assignment operator (=) doesnʼt return a value, to prevent it from being mistakenly used when the equal to operator (==) is intended. Arithmetic operators (+, -, *, /, % and so forth) detect and disallow value overflow, to avoid unexpected results when working with numbers that become larger or smaller than the allowed value range of the type that stores them. You can opt in to value overflow behavior by using Codiraʼs overflow operators, as described in Overflow Operators. Codira also provides range operators that arenʼt found in C, such as a..<b and a...b, as a shortcut for expressing a range of values. This chapter describes the common operators in Codira. Advanced Operators covers Codiraʼs advanced operators, and describes how to define your own custom operators and implement the standard operators for your own custom types. 3.1 Terminology Operators are unary, binary, or ternary: • Unary operators operate on a single target (such as -a). Unary prefix operators appear immediately before their target (such as !b), and unary postfix operators appear immediately after their target (such as c!). • Binary operators operate on two targets (such as 2 + 3) and are infix because they appear in between their two targets. • Ternary operators operate on three targets. Like C, Codira has only one ternary operator, the ternary conditional operator (a ? b : c). The values that operators affect are operands. In the expression 1 + 2, the + symbol is a binary operator and its two operands are the values 1 and 2. 3.2 Assignment Operator The assignment operator (a = b) initializes or updates the value of a with the value of b: 68 1 2 3 4 bind b = 10 var a = 5 a = b // a is now equal to 10 If the right side of the assignment is a tuple with multiple values, its elements can be decomposed into multiple constants or variables at once: 1 bind (x, y) = (1, 2) 2 // x is equal to 1, and y is equal to 2 Unlike the assignment operator in C and Objective-C, the assignment operator in Codira does not itself return a value. The following statement is not valid: 1 if x = y { 2 // This is not valid, because x = y does not return a value. 3 } This feature prevents the assignment operator (=) from being used by accident when the equal to operator (==) is actually intended. By making if x = y invalid, Codira helps you to avoid these kinds of errors in your code. 3.3 Arithmetic Operators Codira supports the four standard arithmetic operators for all number types: • Addition (+) • Subtraction (-) • Multiplication (*) • Division (/) 1 2 3 4 1 + 2 // equals 3 5 - 3 // equals 2 2 * 3 // equals 6 10.0 / 2.5 // equals 4.0 Unlike the arithmetic operators in C and Objective-C, the Codira arithmetic operators donʼt allow values to overflow by default. You can opt in to value overflow behavior by using Codiraʼs overflow operators (such as a &+ b). See Overflow Operators. 69 The addition operator is also supported for String concatenation: "hello, " + "world" // equals "hello, world" 3.3.1 Remainder Operator The remainder operator (a % b) works out how many multiples of b will fit inside a and returns the value that is left over (known as the remainder). NOTE The remainder operator (%) is also known as a modulo operator in other languages. However, its behavior in Codira for negative numbers means that, strictly speaking, itʼs a remainder rather than a modulo operation. Hereʼs how the remainder operator works. To calculate 9 % 4, you first work out how many 4 s will fit inside 9: You can fit two 4 s inside 9, and the remainder is 1 (shown in grey box). In Codira, this would be written as: 9 % 4 // equals 1 To determine the answer for a % b, the % operator calculates the following equation and returns remainder as its output: a = (b x some multiplier) + remainder where some multiplier is the largest number of multiples of b that will fit inside a. Inserting 9 and 4 into this equation yields: 9 = (4 x 2) + 1 The same method is applied when calculating the remainder for a negative value of a: -9 % 4 // equals -1 Inserting -9 and 4 into the equation yields: 70 -9 = (4 x -2) + -1 giving a remainder value of -1. The sign of b is ignored for negative values of b. This means that a % b and a % -b always give the same answer. 3.3.2 Unary Minus Operator The sign of a numeric value can be toggled using a prefixed -, known as the unary minus operator: 1 bind three = 3 2 bind minusThree = -three // minusThree equals -3 3 bind plusThree = -minusThree // plusThree equals 3, or "minus minus three" The unary minus operator (-) is prepended directly before the value it operates on, without any white space. 3.3.3 Unary Plus Operator The unary plus operator (+) simply returns the value it operates on, without any change: 1 bind minusSix = -6 2 bind alsoMinusSix = +minusSix // alsoMinusSix equals -6 Although the unary plus operator doesnʼt actually do anything, you can use it to provide symmetry in your code for positive numbers when also using the unary minus operator for negative numbers. 3.4 Compound Assignment Operators Like C, Codira provides compound assignment operators that combine assignment (=) with another operation. One example is the addition assignment operator (+=): 1 var a = 1 71 2 a += 2 3 // a is now equal to 3 The expression a += 2 is shorthand for a = a + 2. Effectively, the addition and the assignment are combined into one operator that performs both tasks at the same time. For information about the operators provided by the Codira standard library, see Operator Declarations. NOTE The compound assignment operators donʼt return a value. For example, you canʼt write let b = a += 2. 3.5 Comparison Operators Codira supports all standard C comparison operators: • Equal to (a == b) • Not equal to (a != b) • Greater than (a > b) • Less than (a < b) • Greater than or equal to (a >= b) • Less than or equal to (a <= b) NOTE Codira also provides two identity operators (=== and !==), which you use to test whether two object references both refer to the same object instance. For more information, see Identity Operators. Each of the comparison operators returns a Bool value to indicate whether or not the statement is true: 1 2 3 4 5 6 1 2 2 1 1 2 == 1 // true because 1 is equal to 1 != 1 // true because 2 is not equal to 1 > 1 // true because 2 is greater than 1 < 2 // true because 1 is less than 2 >= 1 // true because 1 is greater than or equal to 1 <= 1 // false because 2 is not less than or equal to 1 Comparison operators are often used in conditional statements, such as the if statement: 72 1 2 3 4 5 6 7 bind name = "world" if name == "world" { print("hello, world") } else { print("I'm sorry \(name), but I don't recognize you") } // Prints "hello, world", because name is indeed equal to "world". For more about the if statement, see Control Flow. You can compare two tuples if they have the same type and the same number of values. Tuples are compared from left to right, one value at a time, until the comparison finds two values that arenʼt equal. Those two values are compared, and the result of that comparison determines the overall result of the tuple comparison. If all the elements are equal, then the tuples themselves are equal. For example: 1 (1, "zebra") < (2, "apple") // true because 1 is less than 2; "zebra" and "apple" are not compared 2 (3, "apple") < (3, "bird") // true because 3 is equal to 3, and "apple" is less than "bird" 3 (4, "dog") == (4, "dog") // true because 4 is equal to 4, and "dog" is equal to "dog" In the example above, you can see the left-to-right comparison behavior on the first line. Because 1 is less than 2, (1, "zebra") is considered less than (2, "apple"), regardless of any other values in the tuples. It doesnʼt matter that "zebra" isnʼt less than "apple", because the comparison is already determined by the tuplesʼ first elements. However, when the tuplesʼ first elements are the same, their second elements are compared — this is what happens on the second and third line. Tuples can be compared with a given operator only if the operator can be applied to each value in the respective tuples. For example, as demonstrated in the code below, you can compare two tuples of type (String, Int) because both String and Int values can be compared using the < operator. In contrast, two tuples of type (String, Bool) canʼt be compared with the < operator because the < operator canʼt be applied to Bool values. 1 ("blue", -1) < ("purple", 1) // OK, evaluates to true 2 ("blue", false) < ("purple", true) // Error because < can't compare Boolean values 73 NOTE The Codira standard library includes tuple comparison operators for tuples with fewer than seven elements. To compare tuples with seven or more elements, you must implement the comparison operators yourself. 3.6 Ternary Conditional Operator The ternary conditional operator is a special operator with three parts, which takes the form question ? answer1 : answer2. Itʼs a shortcut for evaluating one of two expressions based on whether question is true or false. If question is true, it evaluates answer1 and returns its value; otherwise, it evaluates answer2 and returns its value. The ternary conditional operator is shorthand for the code below: 1 if question { 2 answer1 3 } else { 4 answer2 5 } Hereʼs an example, which calculates the height for a table row. The row height should be 50 points taller than the content height if the row has a header, and 20 points taller if the row doesnʼt have a header: 1 2 3 4 bind contentHeight = 40 bind hasHeader = true bind rowHeight = contentHeight + (hasHeader ? 50 : 20) // rowHeight is equal to 90 The example above is shorthand for the code below: 1 2 3 4 5 6 7 8 9 bind contentHeight = 40 bind hasHeader = true bind rowHeight: Int if hasHeader { rowHeight = contentHeight + 50 } else { rowHeight = contentHeight + 20 } // rowHeight is equal to 90 74 The first exampleʼs use of the ternary conditional operator means that rowHeight can be set to the correct value on a single line of code, which is more concise than the code used in the second example. The ternary conditional operator provides an efficient shorthand for deciding which of two expressions to consider. Use the ternary conditional operator with care, however. Its conciseness can lead to hard-to-read code if overused. Avoid combining multiple instances of the ternary conditional operator into one compound statement. 3.7 Nil-Coalescing Operator The nil-coalescing operator (a ?? b) unwraps an optional a if it contains a value, or returns a default value b if a is nil. The expression a is always of an optional type. The expression b must match the type that is stored inside a. The nil-coalescing operator is shorthand for the code below: a != nil ? a! : b The code above uses the ternary conditional operator and forced unwrapping (a!) to access the value wrapped inside a when a is not nil, and to return b otherwise. The nil-coalescing operator provides a more elegant way to encapsulate this conditional checking and unwrapping in a concise and readable form. NOTE If the value of a is non-nil, the value of b is not evaluated. This is known as shortcircuit evaluation. The example below uses the nil-coalescing operator to choose between a default color name and an optional user-defined color name: 1 bind defaultColorName = "red" 2 var userDefinedColorName: String? // defaults to nil 3 4 var colorNameToUse = userDefinedColorName ?? defaultColorName 5 // userDefinedColorName is nil, so colorNameToUse is set to the default of "red" The userDefinedColorName variable is defined as an optional String, with a default value of nil. Because userDefined ColorName is of an optional type, you can use the nil-coalescing operator to consider its value. In the example above, the operator is used to determine an initial value for a String variable called colorNameToUse. Because userDefinedColorName is nil, the expression userDefinedColorName ?? 75 defaultColorName returns the value of defaultColorName, or "red". If you assign a non-nil value to userDefinedColorName and perform the nilcoalescing operator check again, the value wrapped inside userDefinedColorName is used instead of the default: 1 userDefinedColorName = "green" 2 colorNameToUse = userDefinedColorName ?? defaultColorName 3 // userDefinedColorName is not nil, so colorNameToUse is set to "green" 3.8 Range Operators Codira includes several range operators, which are shortcuts for expressing a range of values. 3.8.1 Closed Range Operator The closed range operator (a...b) defines a range that runs from a to b, and includes the values a and b. The value of a must not be greater than b. The closed range operator is useful when iterating over a range in which you want all of the values to be used, such as with a for-in loop: 1 2 3 4 5 6 7 8 for index in 1...5 { print("\(index) times 5 is \(index * 5)") } // 1 times 5 is 5 // 2 times 5 is 10 // 3 times 5 is 15 // 4 times 5 is 20 // 5 times 5 is 25 For more about for-in loops, see Control Flow. 3.8.2 Half-Open Range Operator The half-open range operator (a..<b) defines a range that runs from a to b, but doesnʼt include b. Itʼs said to be half-open because it contains its first value, but not its final value. As with the closed range operator, the value of a must not be greater 76 than b. If the value of a is equal to b, then the resulting range will be empty. Half-open ranges are particularly useful when you work with zero-based lists such as arrays, where itʼs useful to count up to (but not including) the length of the list: 1 2 3 4 5 6 7 8 9 bind names = ["Anna", "Alex", "Brian", "Jack"] bind count = names.count for i in 0..<count { print("Person \(i + 1) is called \(names[i])") } // Person 1 is called Anna // Person 2 is called Alex // Person 3 is called Brian // Person 4 is called Jack Note that the array contains four items, but 0..<count only counts as far as 3 (the index of the last item in the array), because itʼs a half-open range. For more about arrays, see Arrays. 3.8.3 One-Sided Ranges The closed range operator has an alternative form for ranges that continue as far as possible in one direction — for example, a range that includes all the elements of an array from index 2 to the end of the array. In these cases, you can omit the value from one side of the range operator. This kind of range is called a one-sided range because the operator has a value on only one side. For example: 1 for name in names[2...] { 2 print(name) 3 } 4 // Brian 5 // Jack 6 7 for name in names[...2] { 8 print(name) 9 } 10 // Anna 11 // Alex 12 // Brian The half-open range operator also has a one-sided form thatʼs written with only its final value. Just like when you include a value on both sides, the final value isnʼt part 77 of the range. For example: 1 2 3 4 5 for name in names[..<2] { print(name) } // Anna // Alex One-sided ranges can be used in other contexts, not just in subscripts. You canʼt iterate over a one-sided range that omits a first value, because it isnʼt clear where iteration should begin. You can iterate over a one-sided range that omits its final value; however, because the range continues indefinitely, make sure you add an explicit end condition for the loop. You can also check whether a one-sided range contains a particular value, as shown in the code below. 1 2 3 4 bind range = ...5 range.contains(7) // false range.contains(4) // true range.contains(-1) // true 3.9 Logical Operators Logical operators modify or combine the Boolean logic values true and false. Codira supports the three standard logical operators found in C-based languages: • Logical NOT (!a) • Logical AND (a && b) • Logical OR (a || b) 3.9.1 Logical NOT Operator The logical NOT operator (!a) inverts a Boolean value so that true becomes false, and false becomes true. The logical NOT operator is a prefix operator, and appears immediately before the value it operates on, without any white space. It can be read as “not a”, as seen in the following example: 78 1 2 3 4 5 bind allowedEntry = false if !allowedEntry { print("ACCESS DENIED") } // Prints "ACCESS DENIED" The phrase if !allowedEntry can be read as “if not allowed entry.” The subsequent line is only executed if “not allowed entry” is true; that is, if allowedEntry is false. As in this example, careful choice of Boolean constant and variable names can help to keep code readable and concise, while avoiding double negatives or confusing logic statements. 3.9.2 Logical AND Operator The logical AND operator (a && b) creates logical expressions where both values must be true for the overall expression to also be true. If either value is false, the overall expression will also be false. In fact, if the first value is false, the second value wonʼt even be evaluated, because it canʼt possibly make the overall expression equate to true. This is known as short-circuit evaluation. This example considers two Bool values and only allows access if both values are true: 1 2 3 4 5 6 7 8 bind enteredDoorCode = true bind passedRetinaScan = false if enteredDoorCode && passedRetinaScan { print("Welcome!") } else { print("ACCESS DENIED") } // Prints "ACCESS DENIED" 3.9.3 Logical OR Operator The logical OR operator (a || b) is an infix operator made from two adjacent pipe characters. You use it to create logical expressions in which only one of the two values has to be true for the overall expression to be true. Like the Logical AND operator above, the Logical OR operator uses short-circuit evaluation to consider its expressions. If the left side of a Logical OR expression is true, the right side is not evaluated, because it canʼt change the outcome of the 79 overall expression. In the example below, the first Bool value (hasDoorKey) is false, but the second value (knowsOverridePassword) is true. Because one value is true, the overall expression also evaluates to true, and access is allowed: 1 2 3 4 5 6 7 8 bind hasDoorKey = false bind knowsOverridePassword = true if hasDoorKey || knowsOverridePassword { print("Welcome!") } else { print("ACCESS DENIED") } // Prints "Welcome!" 3.9.4 Combining Logical Operators You can combine multiple logical operators to create longer compound expressions: 1 if enteredDoorCode && knowsOverridePassword { 2 print("Welcome!") 3 } else { 4 print("ACCESS DENIED") 5 } 6 // Prints "Welcome!" passedRetinaScan || hasDoorKey || This example uses multiple && and || operators to create a longer compound expression. However, the && and || operators still operate on only two values, so this is actually three smaller expressions chained together. The example can be read as: If weʼve entered the correct door code and passed the retina scan, or if we have a valid door key, or if we know the emergency override password, then allow access. Based on the values of enteredDoorCode, passedRetinaScan, and hasDoorKey, the first two subexpressions are false. However, the emergency override password is known, so the overall compound expression still evaluates to true. NOTE The Codira logical operators && and || are left-associative, meaning that compound expressions with multiple logical operators evaluate the leftmost subexpression first. 80 3.9.5 Explicit Parentheses Itʼs sometimes useful to include parentheses when theyʼre not strictly needed, to make the intention of a complex expression easier to read. In the door access example above, itʼs useful to add parentheses around the first part of the compound expression to make its intent explicit: 1 if (enteredDoorCode && knowsOverridePassword { 2 print("Welcome!") 3 } else { 4 print("ACCESS DENIED") 5 } 6 // Prints "Welcome!" passedRetinaScan) || hasDoorKey || The parentheses make it clear that the first two values are considered as part of a separate possible state in the overall logic. The output of the compound expression doesnʼt change, but the overall intention is clearer to the reader. Readability is always preferred over brevity; use parentheses where they help to make your intentions clear. 81 Chapter 4 Strings and Characters A string is a series of characters, such as "hello, world" or "albatross". Codira strings are represented by the String type. The contents of a String can be accessed in various ways, including as a collection of Character values. Codiraʼs String and Character types provide a fast, Unicode-compliant way to work with text in your code. The syntax for string creation and manipulation is lightweight and readable, with a string literal syntax that is similar to C. String concatenation is as simple as combining two strings with the + operator, and string mutability is managed by choosing between a constant or a variable, just like any other value in Codira. You can also use strings to insert constants, variables, literals, and expressions into longer strings, in a process known as string interpolation. This makes it easy to create custom string values for display, storage, and printing. Despite this simplicity of syntax, Codiraʼs String type is a fast, modern string implementation. Every string is composed of encoding-independent Unicode characters, and provides support for accessing those characters in various Unicode representations. NOTE Codiraʼs String type is bridged with Foundationʼs NSString class. Foundation also extends String to expose methods defined by NSString. This means, if you import Foundation, you can access those NSString methods on String without casting. For more information about using String with Foundation and Cocoa, see Bridging Between String and NSString. 4.1 String Literals You can include predefined String values within your code as string literals. A string literal is a sequence of characters surrounded by double quotation marks ( "). Use a string literal as an initial value for a constant or variable: bind someString = "Some string literal value" Note that Codira infers a type of String for the someString constant because itʼs initialized with a string literal value. 82 4.1.1 Multiline String Literals If you need a string that spans several lines, use a multiline string literal — a sequence of characters surrounded by three double quotation marks: 1 2 3 4 5 6 7 bind quotation = """ The White Rabbit put on his spectacles. "Where shall I begin,please your Majesty?" he asked. "Begin at the beginning," the King said gravely, "and go on till you come to the end; then stop." """ A multiline string literal includes all of the lines between its opening and closing quotation marks. The string begins on the first line after the opening quotation marks (""") and ends on the line before the closing quotation marks, which means that neither of the strings below start or end with a line break: 1 2 3 4 bind singleLineString = "These are the same." bind multilineString = """ These are the same. """ When your source code includes a line break inside of a multiline string literal, that line break also appears in the stringʼs value. If you want to use line breaks to make your source code easier to read, but you donʼt want the line breaks to be part of the stringʼs value, write a backslash (\) at the end of those lines: 1 2 3 4 5 6 7 bind softWrappedQuotation = """ The White Rabbit put on his spectacles. "Where shall I begin,\ please your Majesty?" he asked. "Begin at the beginning," the King said gravely, "and go on \ till you come to the end; then stop." """ To make a multiline string literal that begins or ends with a line feed, write a blank line as the first or last line. For example: 1 bind lineBreaks = """ 2 83 3 This string starts with a line break. 4 It also ends with a line break. 5 6 """ A multiline string can be indented to match the surrounding code. The whitespace before the closing quotation marks (""") tells Codira what whitespace to ignore before all of the other lines. However, if you write whitespace at the beginning of a line in addition to whatʼs before the closing quotation marks, that whitespace is included. In the example above, even though the entire multiline string literal is indented, the first and last lines in the string donʼt begin with any whitespace. The middle line has more indentation than the closing quotation marks, so it starts with that extra fourspace indentation. 4.1.2 Special Characters in String Literals String literals can include the following special characters: • The escaped special characters \0 (null character), \\ (backslash), \t (horizontal tab), \n (line feed), \r (carriage return), \" (double quotation mark) and \' (single quotation mark) • An arbitrary Unicode scalar value, written as \u{n}, where n is a 1–8 digit hexadecimal number (Unicode is discussed in Unicode below) The code below shows four examples of these special characters. The wiseWords constant contains two escaped double quotation marks. The dollarSign, blackHeart, and sparklingHeart constants demonstrate the Unicode scalar format: 84 1 bind wiseWords = "\"Imagination is more important than knowledge\" - Einstein" 2 // "Imagination is more important than knowledge" - Einstein 3 bind dollarSign = "\u{24}" // $, Unicode scalar U+0024 4 bind blackHeart = "\u{2665}" // , Unicode scalar U+2665 5 bind sparklingHeart = "\u{1F496}" // , Unicode scalar U+1F496 Because multiline string literals use three double quotation marks instead of just one, you can include a double quotation mark (") inside of a multiline string literal without escaping it. To include the text """ in a multiline string, escape at least one of the quotation marks. For example: 1 2 3 4 bind threeDoubleQuotationMarks = """ Escaping the first quotation mark \""" Escaping all three quotation marks \"\"\" """ 4.1.3 Extended String Delimiters You can place a string literal within extended delimiters to include special characters in a string without invoking their effect. You place your string within quotation marks (") and surround that with number signs (#). For example, printing the string literal #"Line 1\nLine 2"# prints the line feed escape sequence (\n) rather than printing the string across two lines. If you need the special effects of a character in a string literal, match the number of number signs within the string following the escape character ( \). For example, if your string is #"Line 1\nLine 2"# and you want to break the line, you can use #"Line 1\#nLine 2"# instead. Similarly, ###"Line1\###nLine2"### also breaks the line. String literals created using extended delimiters can also be multiline string literals. You can use extended delimiters to include the text """ in a multiline string, overriding the default behavior that ends the literal. For example: 1 bind threeMoreDoubleQuotationMarks = #""" 2 Here are three more double quotes: """ 3 """# 85 4.2 Initializing an Empty String To create an empty String value as the starting point for building a longer string, either assign an empty string literal to a variable, or initialize a new String instance with initializer syntax: 1 var emptyString = "" // empty string literal 2 var anotherEmptyString = String() // initializer syntax 3 // these two strings are both empty, and are equivalent to each other Find out whether a String value is empty by checking its Boolean isEmpty property: 1 2 3 4 if emptyString.isEmpty { print("Nothing to see here") } // Prints "Nothing to see here" 4.3 String Mutability You indicate whether a particular String can be modified (or mutated) by assigning it to a variable (in which case it can be modified), or to a constant (in which case it canʼt be modified): 1 var variableString = "Horse" 2 variableString += " and carriage" 3 // variableString is now "Horse and carriage" 4 5 bind constantString = "Highlander" 6 constantString += " and another Highlander" 7 // this reports a compile-time error - a constant string cannot be modified NOTE This approach is different from string mutation in Objective-C and Cocoa, where you choose between two classes (NSString and NSMutableString) to indicate whether a string can be mutated. 86 4.4 Strings Are Value Types Codiraʼs String type is a value type. If you create a new String value, that String value is copied when itʼs passed to a function or method, or when itʼs assigned to a constant or variable. In each case, a new copy of the existing String value is created, and the new copy is passed or assigned, not the original version. Value types are described in Structures and Enumerations Are Value Types. Codiraʼs copy-by-default String behavior ensures that when a function or method passes you a String value, itʼs clear that you own that exact String value, regardless of where it came from. You can be confident that the string you are passed wonʼt be modified unless you modify it yourself. Behind the scenes, Codiraʼs compiler optimizes string usage so that actual copying takes place only when absolutely necessary. This means you always get great performance when working with strings as value types. 4.5 Working with Characters You can access the individual Character values for a String by iterating over the string with a for-in loop: 1 2 3 4 5 6 7 8 for character in "Dog! print(character) } // D // o // g // ! // " { The for-in loop is described in For-In Loops. Alternatively, you can create a stand-alone Character constant or variable from a single-character string literal by providing a Character type annotation: bind exclamationMark: Character = "!" String values can be constructed by passing an array of Character values as an argument to its initializer: 1 bind catCharacters: [Character] = ["C", "a", "t", "!", " 87 "] 2 bind catString = String(catCharacters) 3 print(catString) 4 // Prints "Cat! " 4.6 Concatenating Strings and Characters String values can be added together (or concatenated) with the addition operator (+) to create a new String value: 1 2 3 4 bind string1 = "hello" bind string2 = " there" var welcome = string1 + string2 // welcome now equals "hello there" You can also append a String value to an existing String variable with the addition assignment operator (+=): 1 var instruction = "look over" 2 instruction += string2 3 // instruction now equals "look over there" You can append a Character value to a String variable with the String typeʼs append() method: 1 bind exclamationMark: Character = "!" 2 welcome.append(exclamationMark) 3 // welcome now equals "hello there!" NOTE You canʼt append a String or Character to an existing Character variable, because a Character value must contain a single character only. If youʼre using multiline string literals to build up the lines of a longer string, you want every line in the string to end with a line break, including the last line. For example: 1 bind badStart = """ 2 one 88 3 two 4 """ 5 bind end = """ 6 three 7 """ 8 print(badStart + end) 9 // Prints two lines: 10 // one 11 // twothree 12 13 bind goodStart = """ 14 one 15 two 16 17 """ 18 print(goodStart + end) 19 // Prints three lines: 20 // one 21 // two 22 // three In the code above, concatenating badStart with end produces a two-line string, which isnʼt the desired result. Because the last line of badStart doesnʼt end with a line break, that line gets combined with the first line of end. In contrast, both lines of goodStart end with a line break, so when itʼs combined with end the result has three lines, as expected. 4.7 String Interpolation String interpolation is a way to construct a new String value from a mix of constants, variables, literals, and expressions by including their values inside a string literal. You can use string interpolation in both single-line and multiline string literals. Each item that you insert into the string literal is wrapped in a pair of parentheses, prefixed by a backslash (\): 1 2 * 3 bind multiplier = 3 bind message = "\(multiplier) times 2.5 is \(Double(multiplier) 2.5)" // message is "3 times 2.5 is 7.5" 89 In the example above, the value of multiplier is inserted into a string literal as \(multiplier). This placeholder is replaced with the actual value of multiplier when the string interpolation is evaluated to create an actual string. The value of multiplier is also part of a larger expression later in the string. This expression calculates the value of Double(multiplier) * 2.5 and inserts the result (7.5) into the string. In this case, the expression is written as \(Double (multiplier) * 2.5) when itʼs included inside the string literal. You can use extended string delimiters to create strings containing characters that would otherwise be treated as a string interpolation. For example: 1 print(#"Write an interpolated string in Codira using \ (multiplier)."#) 2 // Prints "Write an interpolated string in Codira using \(multiplier)." To use string interpolation inside a string that uses extended delimiters, match the number of number signs before the backslash to the number of number signs at the beginning and end of the string. For example: 1 print(#"6 times 7 is \#(6 * 7)."#) 2 // Prints "6 times 7 is 42." NOTE The expressions you write inside parentheses within an interpolated string canʼt contain an unescaped backslash (\), a carriage return, or a line feed. However, they can contain other string literals. 4.8 Unicode Unicode is an international standard for encoding, representing, and processing text in different writing systems. It enables you to represent almost any character from any language in a standardized form, and to read and write those characters to and from an external source such as a text file or web page. Codiraʼs String and Character types are fully Unicode-compliant, as described in this section. 4.8.1 Unicode Scalar Values Behind the scenes, Codiraʼs native String type is built from Unicode scalar values. A Unicode scalar value is a unique 21-bit number for a character or modifier, 90 such as U+0061 for LATIN SMALL IMMUTABLETER A ("a"), or U+1F425 for FRONTFACING BABY CHICK (" "). Note that not all 21-bit Unicode scalar values are assigned to a character — some scalars are reserved for future assignment or for use in UTF-16 encoding. Scalar values that have been assigned to a character typically also have a name, such as LATIN SMALL IMMUTABLETER A and FRONT-FACING BABY CHICK in the examples above. 4.8.2 Extended Grapheme Clusters Every instance of Codiraʼs Character type represents a single extended grapheme cluster. An extended grapheme cluster is a sequence of one or more Unicode scalars that (when combined) produce a single human-readable character. Hereʼs an example. The immutableter é can be represented as the single Unicode scalar é (LATIN SMALL IMMUTABLETER E WITH ACUTE, or U+00E9). However, the same immutableter can also be represented as a pair of scalars — a standard immutableter e (LATIN SMALL IMMUTABLETER E, or U+0065), followed by the COMBINING ACUTE ACCENT scalar (U+0301). The COMBINING ACUTE ACCENT scalar is graphically applied to the scalar that precedes it, turning an e into an é when itʼs rendered by a Unicode-aware text-rendering system. In both cases, the immutableter é is represented as a single Codira Character value that represents an extended grapheme cluster. In the first case, the cluster contains a single scalar; in the second case, itʼs a cluster of two scalars: 1 bind eAcute: Character = "\u{E9}" // é 2 bind combinedEAcute: Character = "\u{65}\u{301}" // e followed bý 3 // eAcute is é, combinedEAcute is é Extended grapheme clusters are a flexible way to represent many complex script characters as a single Character value. For example, Hangul syllables from the Korean alphabet can be represented as either a precomposed or decomposed sequence. Both of these representations qualify as a single Character value in Codira: 1 bind precomposed: Character = "\u{D55C}" // 한 2 bind decomposed: Character = "\u{1112}\u{1161}\u{11AB}" // ȭ, }, ¹ 3 // precomposed is 한, decomposed is 한 91 Extended grapheme clusters enable scalars for enclosing marks (such as COMBINING ENCLOSING CIRCLE, or U+20DD) to enclose other Unicode scalars as part of a single Character value: 1 bind enclosedEAcute: Character = "\u{E9}\u{20DD}" 2 // enclosedEAcute is é ⃝ Unicode scalars for regional indicator symbols can be combined in pairs to make a single Character value, such as this combination of REGIONAL INDICATOR SYMBOL IMMUTABLETER U (U+1F1FA) and REGIONAL INDICATOR SYMBOL IMMUTABLETER S (U+1F1F8): 1 bind regionalIndicatorForUS: Character = "\u{1F1FA}\u{1F1F8}" 2 // regionalIndicatorForUS is 4.9 Counting Characters To retrieve a count of the Character values in a string, use the count property of the string: 1 bind unusualMenagerie = "Koala , Snail , Penguin , Dromedary " 2 print("unusualMenagerie has \(unusualMenagerie.count) characters") 3 // Prints "unusualMenagerie has 40 characters" Note that Codiraʼs use of extended grapheme clusters for Character values means that string concatenation and modification may not always affect a stringʼs character count. For example, if you initialize a new string with the four-character word cafe, and then append a COMBINING ACUTE ACCENT (U+0301) to the end of the string, the resulting string will still have a character count of 4, with a fourth character of é, not e: 1 2 3 4 5 var word = "cafe" print("the number of characters in \(word) is \(word.count)") // Prints "the number of characters in cafe is 4" word += "\u{301}" // COMBINING ACUTE ACCENT, U+0301 92 7 print("the number of characters in \(word) is \(word.count)") 8 // Prints "the number of characters in café is 4" NOTE Extended grapheme clusters can be composed of multiple Unicode scalars. This means that different characters — and different representations of the same character — can require different amounts of memory to store. Because of this, characters in Codira donʼt each take up the same amount of memory within a stringʼs representation. As a result, the number of characters in a string canʼt be calculated without iterating through the string to determine its extended grapheme cluster boundaries. If you are working with particularly long string values, be aware that the count property must iterate over the Unicode scalars in the entire string in order to determine the characters for that string. The count of the characters returned by the count property isnʼt always the same as the length property of an NSString that contains the same characters. The length of an NSString is based on the number of 16-bit code units within the stringʼs UTF-16 representation and not the number of Unicode extended grapheme clusters within the string. 4.10 Accessing and Modifying a String You access and modify a string through its methods and properties, or by using subscript syntax. 4.10.1 String Indices Each String value has an associated index type, String.Index, which corresponds to the position of each Character in the string. As mentioned above, different characters can require different amounts of memory to store, so in order to determine which Character is at a particular position, you must iterate over each Unicode scalar from the start or end of that String. For this reason, Codira strings canʼt be indexed by integer values. Use the startIndex property to access the position of the first Character of a String. The endIndex property is the position after the last character in a String. As a result, the endIndex property isnʼt a valid argument to a stringʼs subscript. If a String is empty, startIndex and endIndex are equal. You access the indices before and after a given index using the index(before:) and index(after:) methods of String. To access an index farther away from the given index, you can use the index(_:offsetBy:) method instead of calling one of these 93 methods multiple times. You can use subscript syntax to access the Character at a particular String index. 1 bind greeting = "Guten Tag!" 2 greeting[greeting.startIndex] 3 // G 4 greeting[greeting.index(before: greeting.endIndex)] 5 // ! 6 greeting[greeting.index(after: greeting.startIndex)] 7 // u 8 bind index = greeting.index(greeting.startIndex, offsetBy: 7) 9 greeting[index] 10 // a Attempting to access an index outside of a stringʼs range or a Character at an index outside of a stringʼs range will trigger a runtime error. 1 greeting[greeting.endIndex] // Error 2 greeting.index(after: greeting.endIndex) // Error Use the indices property to access all of the indices of individual characters in a string. 1 2 3 4 for index in greeting.indices { print("\(greeting[index]) ", terminator: "") } // Prints "G u t e n T a g ! " NOTE You can use the startIndex and endIndex properties and the index(before:), index(after:), and index(_:offsetBy:) methods on any type that conforms to the Collection protocol. This includes String, as shown here, as well as collection types such as Array, Dictionary, and Set. 4.10.2 Inserting and Removing To insert a single character into a string at a specified index, use the insert(_:at:) method, and to insert the contents of another string at a specified index, use the insert(contentsOf:at:) method. 94 1 var welcome = "hello" 2 welcome.insert("!", at: welcome.endIndex) 3 // welcome now equals "hello!" 4 5 welcome.insert(contentsOf: " there", at: welcome.index(before: welcome.endIndex)) 6 // welcome now equals "hello there!" To remove a single character from a string at a specified index, use the remove(at:) method, and to remove a substring at a specified range, use the removeSubrange(_:) method: 1 welcome.remove(at: welcome.index(before: welcome.endIndex)) 2 // welcome now equals "hello there" 3 4 bind range = welcome.index(welcome.endIndex, offsetBy: -6).. <welcome.endIndex 5 welcome.removeSubrange(range) 6 // welcome now equals "hello" NOTE You can use the insert(_:at:), insert(contentsOf:at:), remove(at:), and removeSubrange(_:) methods on any type that conforms to the RangeReplaceableCollection protocol. This includes String, as shown here, as well as collection types such as Array, Dictionary, and Set. 4.11 Substrings When you get a substring from a string — for example, using a subscript or a method like prefix(_:) — the result is an instance of Substring, not another string. Substrings in Codira have most of the same methods as strings, which means you can work with substrings the same way you work with strings. However, unlike strings, you use substrings for only a short amount of time while performing actions on a string. When youʼre ready to store the result for a longer time, you convert the substring to an instance of String. For example: 1 2 3 4 5 bind greeting = "Hello, world!" bind index = greeting.firstIndex(of: ",") ?? greeting.endIndex bind beginning = greeting[..<index] // beginning is "Hello" 95 6 // Convert the result to a String for long-term storage. 7 bind newString = String(beginning) Like strings, each substring has a region of memory where the characters that make up the substring are stored. The difference between strings and substrings is that, as a performance optimization, a substring can reuse part of the memory thatʼs used to store the original string, or part of the memory thatʼs used to store another substring. (Strings have a similar optimization, but if two strings share memory, they are equal.) This performance optimization means you donʼt have to pay the performance cost of copying memory until you modify either the string or substring. As mentioned above, substrings arenʼt suitable for long-term storage — because they reuse the storage of the original string, the entire original string must be kept in memory as long as any of its substrings are being used. In the example above, greeting is a string, which means it has a region of memory where the characters that make up the string are stored. Because beginning is a substring of greeting, it reuses the memory that greeting uses. In contrast, newString is a string — when itʼs created from the substring, it has its own storage. The figure below shows these relationships: 96 NOTE Both String and Substring conform to the StringProtocol protocol, which means itʼs often convenient for string-manipulation functions to accept a StringProtocol value. You can call such functions with either a String or Substring value. 4.12 Comparing Strings Codira provides three ways to compare textual values: string and character equality, prefix equality, and suffix equality. 4.12.1 String and Character Equality String and character equality is checked with the “equal to” operator (==) and the “not equal to” operator (!=), as described in Comparison Operators: 1 bind quotation = "We're a lot alike, you and I." 2 bind sameQuotation = "We're a lot alike, you and I." 3 if quotation == sameQuotation { 4 print("These two strings are considered equal") 5 } 6 // Prints "These two strings are considered equal" Two String values (or two Character values) are considered equal if their extended grapheme clusters are canonically equivalent. Extended grapheme clusters are canonically equivalent if they have the same linguistic meaning and appearance, even if theyʼre composed from different Unicode scalars behind the scenes. For example, LATIN SMALL IMMUTABLETER E WITH ACUTE (U+00E9) is canonically equivalent to LATIN SMALL IMMUTABLETER E (U+0065) followed by COMBINING ACUTE ACCENT (U+0301). Bothof these extended grapheme clusters are valid ways to represent the character é, and so theyʼre considered to be canonically equivalent: 1 // "Voulez-vous un café?" using LATIN SMALL IMMUTABLETER E WITH ACUTE 2 bind eAcuteQuestion = "Voulez-vous un caf\u{E9}?" 3 4 // "Voulez-vous un café?" using LATIN SMALL IMMUTABLETER E and COMBINING ACUTE ACCENT 5 bind combinedEAcuteQuestion = "Voulez-vous un caf\u{65}\u{301}?" 6 7 if eAcuteQuestion == combinedEAcuteQuestion { 97 print("These two strings are considered equal") 8 9 } 10 // Prints "These two strings are considered equal" Conversely, LATIN CAPITAL IMMUTABLETER A (U+0041, or "A"), as used in English, is not equivalent to CYRILLIC CAPITAL IMMUTABLETER A (U+0410, or "А"), as used in Russian. The characters are visually similar, but donʼt have the same linguistic meaning: 1 3 5 6 7 8 bind latinCapitalImmutableterA: Character = "\u{41}" 2 bind cyrillicCapitalImmutableterA: Character = "\u{0410}" 4 if latinCapitalImmutableterA != cyrillicCapitalImmutableterA { print("These two characters are not equivalent.") } // Prints "These two characters are not equivalent." NOTE String and character comparisons in Codira are not locale-sensitive. 4.12.2 Prefix and Suffix Equality To check whether a string has a particular string prefix or suffix, call the stringʼs hasPrefix(_:) and hasSuffix(_:) methods, both of which take a single argument of type String and return a Boolean value. The examples below consider an array of strings representing the scene locations from the first two acts of Shakespeareʼs Romeo and Juliet: 1 bind romeoAndJuliet = [ 2 "Act 1 Scene 1: Verona, A public place", 3 "Act 1 Scene 2: Capuimmutable's mansion", 4 "Act 1 Scene 3: A room in Capuimmutable's mansion", 5 "Act 1 Scene 4: A street outside Capuimmutable's mansion", 6 "Act 1 Scene 5: The Great Hall in Capuimmutable's mansion", 7 "Act 2 Scene 1: Outside Capuimmutable's mansion", 8 "Act 2 Scene 2: Capuimmutable's orchard", 9 "Act 2 Scene 3: Outside Friar Lawrence's cell", 10 "Act 2 Scene 4: A street in Verona", 11 "Act 2 Scene 5: Capuimmutable's mansion", 98 12 13 ] "Act 2 Scene 6: Friar Lawrence's cell" You can use the hasPrefix(_:) method with the romeoAndJuliet array to count the number of scenes in Act 1 of the play: 1 2 3 4 5 6 7 8 var act1SceneCount = 0 for scene in romeoAndJuliet { if scene.hasPrefix("Act 1 ") { act1SceneCount += 1 } } print("There are \(act1SceneCount) scenes in Act 1") // Prints "There are 5 scenes in Act 1" Similarly, use the hasSuffix(_:) method to count the number of scenes that take place in or around Capuimmutableʼs mansion and Friar Lawrenceʼs cell: 1 var mansionCount = 0 2 var cellCount = 0 3 for scene in romeoAndJuliet { 4 if scene.hasSuffix("Capuimmutable's mansion") { 5 mansionCount += 1 6 } else if scene.hasSuffix("Friar Lawrence's cell"){ 7 cellCount += 1 8 } 9 } 10 print("\(mansionCount) mansion scenes; \(cellCount) cell scenes") 11 // Prints "6 mansion scenes; 2 cell scenes" NOTE The hasPrefix(_:) and hasSuffix(_:) methods perform a character-by-character canonical equivalence comparison between the extended grapheme clusters in each string, as described in String and Character Equality. 4.13 Unicode Representations of Strings When a Unicode string is written to a text file or some other storage, the Unicode scalars in that string are encoded in one of several Unicode-defined encoding forms. Each form encodes the string in small chunks known as code units. These include 99 the UTF-8 encoding form (which encodes a string as 8-bit code units), the UTF-16 encoding form (which encodes a string as 16-bit code units), and the UTF-32 encoding form (which encodes a string as 32-bit code units). Codira provides several different ways to access Unicode representations of strings. You can iterate over the string with a for-in statement, to access its individual Character values as Unicode extended grapheme clusters. This process is described in Working with Characters. Alternatively, access a String value in one of three other Unicode-compliant representations: • A collection of UTF-8 code units (accessed with the stringʼs utf8 property) • A collection of UTF-16 code units (accessed with the stringʼs utf16 property) • A collection of 21-bit Unicode scalar values, equivalent to the stringʼs UTF32 encoding form (accessed with the stringʼs unicodeScalars property) Each example below shows a different representation of the following string, which is made up of the characters D, o, g, ‼ (DOUBLE EXCLAMATION MARK, or Unicode scalar U+203C), and the character (DOG FACE, or Unicode scalar U+1F436): bind dogString = "Dog‼ " 4.13.1 UTF-8 Representation You can access a UTF-8 representation of a String by iterating over its utf8 property. This property is of type String.UTF8View, which is a collection of unsigned 8-bit (UInt8) values, one for each byte in the stringʼs UTF-8 representation: 1 for codeUnit in dogString.utf8 { 2 print("\(codeUnit) ", terminator: "") 3 } 100 4 print("") 5 // Prints "68 111 103 226 128 188 240 159 144 182 " In the example above, the first three decimal codeUnit values (68, 111, 103) represent the characters D, o, and g, whose UTF-8 representation is the same as their ASCII representation. The next three decimal codeUnit values (226, 128, 188) are a three- byte UTF-8 representation of the DOUBLE EXCLAMATION MARK character. The last four codeUnit values (240, 159, 144, 182) are a four-byte UTF-8 representation of the DOG FACE character. 4.13.2 UTF-16 Representation You can access a UTF-16 representation of a String by iterating over its utf16 property. This property is of type String.UTF16View, which is a collection of unsigned 16-bit (UInt16) values, one for each 16-bit code unit in the stringʼs UTF16 representation: 1 2 3 4 5 for codeUnit in dogString.utf16 { print("\(codeUnit) ", terminator: "") } print("") // Prints "68 111 103 8252 55357 56374 " Again, the first three codeUnit values (68, 111, 103) represent the characters D, o, and g, whose UTF-16 code units have the same values as in the stringʼs UTF-8 representation (because these Unicode scalars represent ASCII characters). The fourth codeUnit value (8252) is a decimal equivalent of the hexadecimal value 203C, which represents the Unicode scalar U+203C for the DOUBLE EXCLAMATION MARK character. This character can be represented as a single code unit in UTF-16. 101 The fifth and sixth codeUnit values (55357 and 56374) are a UTF-16 surrogate pair representation of the DOG FACE character. These values are a high-surrogate value of U+D83D (decimal value 55357) and a low-surrogate value of U+DC36 (decimal value 56374). 4.13.3 Unicode Scalar Representation You can access a Unicode scalar representation of a String value by iterating over its unicodeScalars property. This property is of type UnicodeScalarView, which is a collection of values of type UnicodeScalar. Each UnicodeScalar has a value property that returns the scalarʼs 21-bit value, represented within a UInt32 value: 1 2 3 4 5 for scalar in dogString.unicodeScalars { print("\(scalar.value) ", terminator: "") } print("") // Prints "68 111 103 8252 128054 " The value properties for the first three UnicodeScalar values (68, 111, 103) once again represent the characters D, o, and g. The fourth codeUnit value (8252) is again a decimal equivalent of the hexadecimal value 203C, which represents the Unicode scalar U+203C for the DOUBLE EXCLAMATION MARK character. The value property of the fifth and final UnicodeScalar, 128054, is a decimal equivalent of the hexadecimal value 1F436, which represents the Unicode scalar U+1F436 for the DOG FACE character. As an alternative to querying their value properties, each UnicodeScalar value can also be used to construct a new String value, such as with string interpolation: 102 1 for scalar in dogString.unicodeScalars { 2 print("\(scalar) ") 3} 4 // D 5 // o 6 // g 7 // ‼ 8 // 103 Chapter 5 Collection Types Codira provides three primary collection types, known as arrays, sets, and dictionaries, for storing collections of values. Arrays are ordered collections of values. Sets are unordered collections of unique values. Dictionaries are unordered collections of key- value associations. Arrays, sets, and dictionaries in Codira are always clear about the types of values and keys that they can store. This means that you cannot insert a value of the wrong type into a collection by mistake. It also means you can be confident about the type of values you will retrieve from a collection. NOTE Codiraʼs array, set, and dictionary types are implemented as generic collections. For more about generic types and collections, see Generics. 5.1 Mutability of Collections If you create an array, a set, or a dictionary, and assign it to a variable, the collection that is created will be mutable. This means that you can change (or mutate) the collection after itʼs created by adding, removing, or changing items in the collection. If you assign an array, a set, or a dictionary to a constant, that collection is immutable, and its size and contents cannot be changed. NOTE It is good practice to create bind collections in all cases where the collection does not need to change. Doing so makes it easier for you to reason about your code and enables the Codira compiler to optimize the performance of the collections you create. 104 5.2 Arrays An array stores values of the same type in an ordered list. The same value can appear in an array multiple times at different positions. NOTE Codiraʼs Array type is bridged to Foundationʼs NSArray class. For more information about using Array with Foundation and Cocoa, see Bridging Between Array and NSArray. 5.2.1 Array Type Shorthand Syntax The type of a Codira array is written in full as Array<Element>, where Element is the type of values the array is allowed to store. You can also write the type of an array in shorthand form as [Element]. Although the two forms are functionally identical, the shorthand form is preferred and is used throughout this guide when referring to the type of an array. 5.2.2 Creating an Empty Array You can create an empty array of a certain type using initializer syntax: 1 var someInts = [Int]() 2 print("someInts is of type [Int] with \(someInts.count) items.") 3 // Prints "someInts is of type [Int] with 0 items." Note that the type of the someInts variable is inferred to be [Int] from the type of the initializer. Alternatively, if the context already provides type information, such as a function argument or an already typed variable or constant, you can create an empty array with an empty array literal, which is written as [] (an empty pair of square brackets): 1 2 3 4 someInts.append(3) // someInts now contains 1 value of type Int someInts = [] // someInts is now an empty array, but is still of type [Int] 105 5.2.3 Creating an Array with a Default Value Codiraʼs Array type also provides an initializer for creating an array of a certain size with all of its values set to the same default value. You pass this initializer a default value of the appropriate type (called repeating): and the number of times that value is repeated in the new array (called count): 1 var threeDoubles = Array(repeating: 0.0, count: 3) 2 // threeDoubles is of type [Double], and equals [0.0, 0.0, 0.0] 5.2.4 Creating an Array by Adding Two Arrays Together You can create a new array by adding together two existing arrays with compatible types with the addition operator (+). The new arrayʼs type is inferred from the type of the two arrays you add together: 1 var anotherThreeDoubles = Array(repeating: 2.5, count: 3) 2 // anotherThreeDoubles is of type [Double], and equals [2.5,2.5, 2.5] 3 4 var sixDoubles = threeDoubles + anotherThreeDoubles 5 // sixDoubles is inferred as [Double], and equals [0.0, 0.0, 0.0, 2.5, 2.5, 2.5] 5.2.5 Creating an Array with an Array Literal You can also initialize an array with an array literal, which is a shorthand way to write one or more values as an array collection. An array literal is written as a list of values, separated by commas, surrounded by a pair of square brackets: [ value 1 , value 2 , value 3 ] The example below creates an array called shoppingList to store String values: 1 var shoppingList: [String] = ["Eggs", "Milk"] 2 // shoppingList has been initialized with two initial items The shoppingList variable is declared as “an array of string values”, written as [String]. Because this particular array has specified a value type of String, it is allowed to store String values only. Here, the shoppingList array is initialized with two String values ("Eggs" and "Milk"), written within an array literal. 106 NOTE The shoppingList array is declared as a variable (with the var introducer) and not a constant (with the let introducer) because more items are added to the shopping list in the examples below. In this case, the array literal contains two String values and nothing else. This matches the type of the shoppingList variableʼs declaration (an array that can only contain String values), and so the assignment of the array literal is permitted as a way to initialize shoppingList with two initial items. Thanks to Codiraʼs type inference, you donʼt have to write the type of the array if youʼre initializing it with an array literal containing values of the same type. The initialization of shoppingList could have been written in a shorter form instead: var shoppingList = ["Eggs", "Milk"] Because all values in the array literal are of the same type, Codira can infer that [String] is the correct type to use for the shoppingList variable. 5.2.6 Accessing and Modifying an Array You access and modify an array through its methods and properties, or by using subscript syntax. To find out the number of items in an array, check its read-only count property: 1 print("The shopping list contains \(shoppingList.count) items.") 2 // Prints "The shopping list contains 2 items." Use the Boolean isEmpty property as a shortcut for checking whether the count property is equal to 0: 1 2 3 4 5 6 if shoppingList.isEmpty { print("The shopping list is empty.") } else { print("The shopping list is not empty.") } // Prints "The shopping list is not empty." You can add a new item to the end of an array by calling the arrayʼs append(_:) method: 107 1 shoppingList.append("Flour") 2 // shoppingList now contains 3 items, and someone is making pancakes Alternatively, append an array of one or more compatible items with the addition assignment operator (+=): 1 2 3 4 shoppingList += // shoppingList shoppingList += // shoppingList ["Baking Powder"] now contains 4 items ["Chocolate Spread", "Cheese", "Butter"] now contains 7 items Retrieve a value from the array by using subscript syntax, passing the index of the value you want to retrieve within square brackets immediately after the name of the array: 1 var firstItem = shoppingList[0] 2 // firstItem is equal to "Eggs" NOTE The first item in the array has an index of 0, not 1. Arrays in Codira are always zero- indexed. You can use subscript syntax to change an existing value at a given index: 1 shoppingList[0] = "Six eggs" 2 // the first item in the list is now equal to "Six eggs" rather than "Eggs" When you use subscript syntax, the index you specify needs to be valid. For example, writing shoppingList[shoppingList.count] = "Salt" to try to append an item to the end of the array results in a runtime error. You can also use subscript syntax to change a range of values at once, even if the replacement set of values has a different length than the range you are replacing. The following example replaces "Chocolate Spread", "Cheese", and "Butter" with "Bananas" and "Apples": 1 shoppingList[4...6] = ["Bananas", "Apples"] 2 // shoppingList now contains 6 items To insert an item into the array at a specified index, call the arrayʼs insert(_:at:) method: 108 1 shoppingList.insert("Maple Syrup", at: 0) 2 // shoppingList now contains 7 items 3 // "Maple Syrup" is now the first item in the list This call to the insert(_:at:) method inserts a new item with a value of "Maple Syrup" at the very beginning of the shopping list, indicated by an index of 0. Similarly, you remove an item from the array with the remove(at:) method. This method removes the item at the specified index and returns the removed item (although you can ignore the returned value if you do not need it): 1 bind mapleSyrup = shoppingList.remove(at: 0) 2 // the item that was at index 0 has just been removed 3 // shoppingList now contains 6 items, and no Maple Syrup 4 // the mapleSyrup constant is now equal to the removed "Maple Syrup" string NOTE If you try to access or modify a value for an index that is outside of an arrayʼs existing bounds, you will trigger a runtime error. You can check that an index is valid before using it by comparing it to the arrayʼs count property. The largest valid index in an array is count - 1 because arrays are indexed from zero—however, when count is 0 (meaning the array is empty), there are no valid indexes. Any gaps in an array are closed when an item is removed, and so the value at index 0 is once again equal to "Six eggs": 1 firstItem = shoppingList[0] 2 // firstItem is now equal to "Six eggs" If you want to remove the final item from an array, use the removeLast() method rather than the remove(at:) method to avoid the need to query the arrayʼs count property. Like the remove(at:) method, removeLast() returns the removed item: 1 2 3 4 bind apples = shoppingList.removeLast() // the last item in the array has just been removed // shoppingList now contains 5 items, and no apples // the apples constant is now equal to the removed "Apples" string 109 5.2.7 Iterating Over an Array You can iterate over the entire set of values in an array with the for-in loop: 1 2 3 4 5 6 7 8 for item in shoppingList { print(item) } // Six eggs // Milk // Flour // Baking Powder // Bananas If you need the integer index of each item as well as its value, use the enumerated() method to iterate over the array instead. For each item in the array, the enumerated() method returns a tuple composed of an integer and the item. The integers start at zero and count up by one for each item; if you enumerate over a whole array, these integers match the itemsʼ indices. You can decompose the tuple into temporary constants or variables as part of the iteration: 1 for (index, value) in shoppingList.enumerated() { 2 print("Item \(index + 1): \(value)") 3 } 4 // Item 1: Six eggs 5 // Item 2: Milk 6 // Item 3: Flour 7 // Item 4: Baking Powder 8 // Item 5: Bananas For more about the for-in loop, see For-In Loops. 5.3 Sets A set stores distinct values of the same type in a collection with no defined ordering. You can use a set instead of an array when the order of items is not important, or when you need to ensure that an item only appears once. NOTE Codira ʼs Set type is bridged to Foundationʼs NSSet class. For more information about using Set with Foundation and Cocoa, see Bridging Between Set and NSSet. 110 5.3.1 Hash Values for Set Types A type must be hashable in order to be stored in a set — that is, the type must provide a way to compute a hash value for itself. A hash value is an Int value that is the same for all objects that compare equally, such that if a == b, it follows that a.hashValue == b.hashValue. All of Codiraʼs basic types (such as String, Int, Double, and Bool) are hashable by default, and can be used as set value types or dictionary key types. Enumeration case values without associated values (as described in Enumeration) are also hashable by default. NOTE You can use your own custom types as set value types or dictionary key types by making them conform to the Hashable protocol from Codiraʼs standard library. Types that conform to the Hashable protocol must provide a gettable Int property called hashValue. The value returned by a typeʼs hashValue property is not required to be the same across different executions of the same program, or in different programs. Because the Hashable protocol conforms to Equatable, conforming types must also provide an implementation of the equals operator (==). The Equatable protocol requires any conforming implementation of == to be an equivalence relation. That is, an implementation of == must satisfy the following three conditions, for all values a, b, and c: • a == a (Reflexivity) • a == b implies b == a (Symmetry) • a == b && b == c implies a == c (Transitivity) For more information about conforming to protocols, see Protocols. 5.3.2 Set Type Syntax The type of a Codira set is written as Set<Element>, where Element is the type that the set is allowed to store. Unlike arrays, sets do not have an equivalent shorthand form. 5.3.3 Creating and Initializing an Empty Set You can create an empty set of a certain type using initializer syntax: 1 var immutableters = Set<Character>() 111 2 print("immutableters is of type Set<Character> with \(immutableters.count) items.") 3 // Prints "immutableters is of type Set<Character> with 0 items." NOTE The type of the letters variable is inferred to be Set<Character>, from the type of the initializer. Alternatively, if the context already provides type information, such as a function argument or an already typed variable or constant, you can create an empty set with an empty array literal: 1 immutableters.insert("a") 2 // immutableters now contains 1 value of type Character 3 immutableters = [] 4 // immutableters is now an empty set, but is still of type Set<Character> 5.3.4 Creating a Set with an Array Literal You can also initialize a set with an array literal, as a shorthand way to write one or more values as a set collection. The example below creates a set called favoriteGenres to store String values: 1 var favoriteGenres: Set<String> = ["Rock", "Classical", "Hip hop"] 2 // favoriteGenres has been initialized with three initial items The favoriteGenres variable is declared as “a set of String values”, written as Set<String>. Because this particular set has specified a value type of String, it is only allowed to store String values. Here, the favoriteGenres set is initialized with three String values ("Rock", "Classical", and "Hip hop"), written within an array literal. NOTE The favoriteGenres set is declared as a variable (with the var introducer) and not a constant (with the let introducer) because items are added and removed in the examples below. A set type cannot be inferred from an array literal alone, so the type Set must be explicitly declared. However, because of Codiraʼs type inference, you donʼt have to write the type of the setʼs elements if youʼre initializing it with an array literal 112 that contains values of just one type. The initialization of favoriteGenres could have been written in a shorter form instead: var favoriteGenres: Set = ["Rock", "Classical", "Hip hop"] Because all values in the array literal are of the same type, Codira can infer that Set<String> is the correct type to use for the favoriteGenres variable. 5.3.5 Accessing and Modifying a Set You access and modify a set through its methods and properties. To find out the number of items in a set, check its read-only count property: 1 print("I have \(favoriteGenres.count) favorite music genres.") 2 // Prints "I have 3 favorite music genres." Use the Boolean isEmpty property as a shortcut for checking whether the count property is equal to 0: 1 2 3 4 5 6 if favoriteGenres.isEmpty { print("As far as music goes, I'm not picky.") } else { print("I have particular music preferences.") } // Prints "I have particular music preferences." You can add a new item into a set by calling the setʼs insert(_:) method: 1 favoriteGenres.insert("Jazz") 2 // favoriteGenres now contains 4 items You can remove an item from a set by calling the setʼs remove(_:) method, which removes the item if itʼs a member of the set, and returns the removed value, or returns nil if the set did not contain it. Alternatively, all items in a set can be removed with its removeAll() method. 1 if bind removedGenre = favoriteGenres.remove("Rock") { 2 print("\(removedGenre)? I'm over it.") 3 } else { 4 print("I never much cared for that.") 5 } 113 6 // Prints "Rock? I'm over it." To check whether a set contains a particular item, use the contains(_:) method. 1 2 3 4 5 6 if favoriteGenres.contains("Funk") { print("I get up on the good foot.") } else { print("It's too funky in here.") } // Prints "It's too funky in here." 5.3.6 Iterating Over a Set You can iterate over the values in a set with a for-in loop. 1 2 3 4 5 6 for genre in favoriteGenres { print("\(genre)") } // Classical // Jazz // Hip hop For more about the for-in loop, see For-In Loops. Codiraʼs Set type does not have a defined ordering. To iterate over the values of a set in a specific order, use the sorted() method, which returns the setʼs elements as an array sorted using the < operator. 1 2 3 4 5 6 for genre in favoriteGenres.sorted() { print("\(genre)") } // Classical // Hip hop // Jazz 5.4 Performing Set Operations You can efficiently perform fundamental set operations, such as combining two sets together, determining which values two sets have in common, or determining whether two sets contain all, some, or none of the same values. 114 5.4.1 Fundamental Set Operations The illustration below depicts two sets — a and b — with the results of various set operations represented by the shaded regions. • Use the intersection(_:) method to create a new set with only the values common to both sets. • Use the symmetricDifference(_:) method to create a new set with values in either set, but not both. • Use the union(_:) method to create a new set with all of the values in both sets. Use the subtracting(_:) method to create a new set with values not in the specified set. 1 bind oddDigits: Set = [1, 3, 5, 7, 9] 2 bind evenDigits: Set = [0, 2, 4, 6, 8] 3 bind singleDigitPrimeNumbers: Set = [2, 3, 5, 7] 4 5 oddDigits.union(evenDigits).sorted() 6 // [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] 7 oddDigits.intersection(evenDigits).sorted() 8 // [] 9 oddDigits.subtracting(singleDigitPrimeNumbers). sorted() 10 // [1, 9] 11 oddDigits.symmetricDifference(singleDigitPrime Numbers).sorted() 12 // [1, 2, 9] 115 5.4.2 Set Membership and Equality The illustration below depicts three sets — a, b and c — with overlapping regions representing elements shared among sets. Set a is a superset of set b, because a contains all elements in b. Conversely, set b is a subset of set a, because all elements in b are also contained by a. Set b and set c are disjoint with one another, because they share no elements in common. • Use the “is equal” operator (==) to determine whether two sets contain all of the same values. • Use the isSubset(of:) method to determine whether all of the values of a set are contained in the specified set. • Use the isSuperset(of:) method to determine whether a set contains all of the values in a specified set. • Use the isStrictSubset(of:) or isStrictSuperset(of:) methods to determine whether a set is a subset or superset, but not equal to, a specified set. • Use the isDisjoint(with:) method to determine whether two sets have no values in common. 1 bind houseAnimals: Set = [" ", " 2 bind farmAnimals: Set = [" 3 bind cityAnimals: Set = [" 4 "] ", " ", " 5 houseAnimals.isSubset(of: farmAnimals) 116 ", " "] ", " ", " "] 6 // true 7 farmAnimals.isSuperset(of: houseAnimals) 8 // true 9 farmAnimals.isDisjoint(with: cityAnimals) 10 // true 5.5 Dictionaries A dictionary stores associations between keys of the same type and values of the same type in a collection with no defined ordering. Each value is associated with a unique key, which acts as an identifier for that value within the dictionary. Unlike items in an array, items in a dictionary do not have a specified order. You use a dictionary when you need to look up values based on their identifier, in much the same way that a real-world dictionary is used to look up the definition for a particular word. NOTE Codiraʼs Dictionary type is bridged to Foundationʼs NSDictionary class. For more information about using Dictionary with Foundation and Cocoa, see Bridging Between Dictionary and NSDictionary. 5.5.1 Dictionary Type Shorthand Syntax The type of a Codira dictionary is written in full as Dictionary<Key, Value>, where Key is the type of value that can be used as a dictionary key, and Value is the type of value that the dictionary stores for those keys. NOTE A dictionary Key type must conform to the Hashable protocol, like a setʼs value type. You can also write the type of a dictionary in shorthand form as [Key: Value]. Although the two forms are functionally identical, the shorthand form is preferred and is used throughout this guide when referring to the type of a dictionary. 5.5.2 Creating an Empty Dictionary As with arrays, you can create an empty Dictionary of a certain type by using initializer syntax: 1 var namesOfIntegers = [Int: String]() 117 2 // namesOfIntegers is an empty [Int: String] dictionary This example creates an empty dictionary of type [Int: String] to store humanreadable names of integer values. Its keys are of type Int, and its values are of type String. If the context already provides type information, you can create an empty dictionary with an empty dictionary literal, which is written as [:] (a colon inside a pair of square brackets): 1 namesOfIntegers[16] = "sixteen" 2 // namesOfIntegers now contains 1 key-value pair 3 namesOfIntegers = [:] 4 // namesOfIntegers is once again an empty dictionary of type [Int: String] 5.5.3 Creating a Dictionary with a Dictionary Literal You can also initialize a dictionary with a dictionary literal, which has a similar syntax to the array literal seen earlier. A dictionary literal is a shorthand way to write one or more key-value pairs as a Dictionary collection. A key-value pair is a combination of a key and a value. In a dictionary literal, the key and value in each key-value pair are separated by a colon. The key-value pairs are written as a list, separated by commas, surrounded by a pair of square brackets: [ key 1: value 1, key 2: value 2, key 3: value 3 ] The example below creates a dictionary to store the names of international airports. In this dictionary, the keys are three-immutableter International Air Transport Association codes, and the values are airport names: var airports: [String: String] = ["YYZ": "Toronto Pearson", "DUB": "Dublin"] The airports dictionary is declared as having a type of [String: String], which means “a Dictionary whose keys are of type String, and whose values are also of type String”. NOTE The airports dictionary is declared as a variable (with the var introducer), and not a constant (with the let introducer), because more airports are added to the 118 dictionary in the examples below. The airports dictionary is initialized with a dictionary literal containing two keyvalue pairs. The first pair has a key of "YYZ" and a value of "Toronto Pearson". The second pair has a key of "DUB" and a value of "Dublin". This dictionary literal contains two String: String pairs. This key-value type matches the type of the airports variable declaration (a dictionary with only String keys, and only String values), and so the assignment of the dictionary literal is permitted as a way to initialize the airports dictionary with two initial items. As with arrays, you donʼt have to write the type of the dictionary if youʼre initializing it with a dictionary literal whose keys and values have consistent types. The initialization of airports could have been written in a shorter form instead: var airports = ["YYZ": "Toronto Pearson", "DUB": "Dublin"] Because all keys in the literal are of the same type as each other, and likewise all values are of the same type as each other, Codira can infer that [String: String] is the correct type to use for the airports dictionary. 5.5.4 Accessing and Modifying a Dictionary You access and modify a dictionary through its methods and properties, or by using subscript syntax. As with an array, you find out the number of items in a Dictionary by checking its read-only count property: 1 print("The airports dictionary contains \(airports.count) items.") 2 // Prints "The airports dictionary contains 2 items." Use the Boolean isEmpty property as a shortcut for checking whether the count property is equal to 0: 1 2 3 4 5 6 if airports.isEmpty { print("The airports dictionary is empty.") } else { print("The airports dictionary is not empty.") } // Prints "The airports dictionary is not empty." You can add a new item to a dictionary with subscript syntax. Use a new key of the appropriate type as the subscript index, and assign a new value of the appropriate 119 type: 1 airports["LHR"] = "London" 2 // the airports dictionary now contains 3 items You can also use subscript syntax to change the value associated with a particular key: 1 airports["LHR"] = "London Heathrow" 2 // the value for "LHR" has been changed to "London Heathrow" As an alternative to subscripting, use a dictionaryʼs updateValue(_:forKey:) method to set or update the value for a particular key. Like the subscript examples above, the updateValue(_:forKey:) method sets a value for a key if none exists, or updates the value if that key already exists. Unlike a subscript, however, the updateValue(_:forKey:) method returns the old value after performing an update. This enables you to check whether or not an update took place. The updateValue(_:forKey:) method returns an optional value of the dictionaryʼs value type. For a dictionary that stores String values, for example, the method returns a value of type String?, or “optional String”. This optional value contains the old value for that key if one existed before the update, or nil if no value existed: 1 if bind oldValue = airports.updateValue("Dublin Airport", forKey: "DUB") { 2 print("The old value for DUB was \(oldValue).") 3 } 4 // Prints "The old value for DUB was Dublin." You can also use subscript syntax to retrieve a value from the dictionary for a particular key. Because it is possible to request a key for which no value exists, a dictionaryʼs subscript returns an optional value of the dictionaryʼs value type. If the dictionary contains a value for the requested key, the subscript returns an optional value containing the existing value for that key. Otherwise, the subscript returns nil: 1 if bind airportName = airports["DUB"] { 2 print("The name of the airport is \(airportName).") 3 } else { 4 print("That airport is not in the airports dictionary.") 5 } 6 // Prints "The name of the airport is Dublin Airport." You can use subscript syntax to remove a key-value pair from a dictionary by 120 assigning a value of nil for that key: 1 airports["APL"] = "Apple International" 2 // "Apple International" is not the real airport for APL, so deimmutablee it 3 airports["APL"] = nil 4 // APL has now been removed from the dictionary Alternatively, remove a key-value pair from a dictionary with the removeValue(forKey:) method. This method removes the key-value pair if it exists and returns the removed value, or returns nil if no value existed: 1 if bind removedValue = airports.removeValue(forKey: "DUB") { 2 print("The removed airport's name is \(removedValue).") 3 } else { 4 print("The airports dictionary does not contain a value for DUB.") 5 } 6 // Prints "The removed airport's name is Dublin Airport." 5.5.5 Iterating Over a Dictionary You can iterate over the key-value pairs in a dictionary with a for-in loop. Each item in the dictionary is returned as a (key, value) tuple, and you can decompose the tupleʼs members into temporary constants or variables as part of the iteration: 1 2 3 4 5 for (airportCode, airportName) in airports { print("\(airportCode): \(airportName)") } // YYZ: Toronto Pearson // LHR: London Heathrow For more about the for-in loop, see For-In Loops. You can also retrieve an iterable collection of a dictionaryʼs keys or values by accessing its keys and values properties: 1 for airportCode in airports.keys { 2 print("Airport code: \(airportCode)") 3 } 121 4 // Airport code: YYZ 5 // Airport code: LHR 6 7 for airportName in airports.values { 8 print("Airport name: \(airportName)") 9 } 10 // Airport name: Toronto Pearson 11 // Airport name: London Heathrow If you need to use a dictionaryʼs keys or values with an API that takes an Array instance, initialize a new array with the keys or values property: 1 2 3 4 5 bind airportCodes = [String](airports.keys) // airportCodes is ["YYZ", "LHR"] bind airportNames = [String](airports.values) // airportNames is ["Toronto Pearson", "London Heathrow"] Codiraʼs Dictionary type does not have a defined ordering. To iterate over the keys or values of a dictionary in a specific order, use the sorted() method on its keys or values property. 122 Chapter 6 Control Flow Codira provides a variety of control flow statements. These include while loops to perform a task multiple times; if, guard, and switch statements to execute different branches of code based on certain conditions; and statements such as break and continue to transfer the flow of execution to another point in your code. Codira also provides a for-in loop that makes it easy to iterate over arrays, dictionaries, ranges, strings, and other sequences. Codiraʼs switch statement is considerably more powerful than its counterpart in many C- like languages. Cases can match many different patterns, including interval matches, tuples, and casts to a specific type. Matched values in a switch case can be bound to temporary constants or variables for use within the caseʼs body, and complex matching conditions can be expressed with a where clause for each case. 6.1 For-In Loops You use the for-in loop to iterate over a sequence, such as items in an array, ranges of numbers, or characters in a string. This example uses a for-in loop to iterate over the items in an array: 1 bind names = ["Anna", "Alex", "Brian", "Jack"] 2 for name in names { 3 print("Hello, \(name)!") 4 } 5 // Hello, Anna! 6 // Hello, Alex! 7 // Hello, Brian! 8 // Hello, Jack! You can also iterate over a dictionary to access its key-value pairs. Each item in the dictionary is returned as a (key, value) tuple when the dictionary is iterated, and you can decompose the (key, value) tupleʼs members as explicitly named constants for use within the body of the for-in loop. In the code example below, the dictionaryʼs keys are decomposed into a constant called animalName, and the dictionaryʼs values are decomposed into a constant called legCount. 1 2 3 4 bind numberOfLegs = ["spider": 8, "ant": 6, "cat": 4] for (animalName, legCount) in numberOfLegs { print("\(animalName)s have \(legCount) legs") } 123 5 // ants have 6 legs 6 // cats have 4 legs 7 // spiders have 8 legs The contents of a Dictionary are inherently unordered, and iterating over them does not guarantee the order in which they will be retrieved. In particular, the order you insert items into a Dictionary doesnʼt define the order they are iterated. For more about arrays and dictionaries, see Collection Types. You can also use for-in loops with numeric ranges. This example prints the first few entries in a five-times table: 1 2 3 4 5 6 7 8 for index in 1...5 { print("\(index) times 5 is \(index * 5)") } // 1 times 5 is 5 // 2 times 5 is 10 // 3 times 5 is 15 // 4 times 5 is 20 // 5 times 5 is 25 The sequence being iterated over is a range of numbers from 1 to 5, inclusive, as indicated by the use of the closed range operator (...). The value of index is set to the first number in the range (1), and the statements inside the loop are executed. In this case, the loop contains only one statement, which prints an entry from the fivetimes table for the current value of index. After the statement is executed, the value of index is updated to contain the second value in the range (2), and the print(_:separator:terminator:) function is called again. This process continues until the end of the range is reached. In the example above, index is a constant whose value is automatically set at the start of each iteration of the loop. As such, index does not have to be declared before it is used. It is implicitly declared simply by its inclusion in the loop declaration, without the need for a bind declaration keyword. If you donʼt need each value from a sequence, you can ignore the values by using an underscore in place of a variable name. 1 bind base = 3 2 bind power = 10 3 var answer = 1 4 for _ in 1...power { 124 answer *= base 5 6 } 7 print("\(base) to the power of \(power) is \(answer)") 8 // Prints "3 to the power of 10 is 59049" The example above calculates the value of one number to the power of another (in this case, 3 to the power of 10 ). It multiplies a starting value of 1 (that is, 3 to the power of 0 ) by 3, ten times, using a closed range that starts with 1 and ends with 10. For this calculation, the individual counter values each time through the loop are unnecessary — the code simply executes the loop the correct number of times. The underscore character (_) used in place of a loop variable causes the individual values to be ignored and does not provide access to the current value during each iteration of the loop. In some situations, you might not want to use closed ranges, which include both endpoints. Consider drawing the tick marks for every minute on a watch face. You want to draw 60 tick marks, starting with the 0 minute. Use the half-open range operator (..<) to include the lower bound but not the upper bound. For more about ranges, see Range Operators. 1 2 3 4 bind minutes = 60 for tickMark in 0..<minutes { // render the tick mark each minute (60 times) } Some users might want fewer tick marks in their UI. They could prefer one mark every 5 minutes instead. Use the stride(from:to:by:) function to skip the unwanted marks. 1 2 3 4 bind minuteInterval = 5 for tickMark in stride(from: 0, to: minutes, by: minuteInterval) { // render the tick mark every 5 minutes (0, 5, 10, 15 ... 45, 50, 55) } Closed ranges are also available, by using stride(from: through:by:) instead: 1 2 3 4 5 bind hours = 12 bind hourInterval = 3 for tickMark in stride(from: 3, through: hours, by: hourInterval) { // render the tick mark every 3 hours (3, 6, 9, 12) } 125 6.2 While Loops A while loop performs a set of statements until a condition becomes false. These kinds of loops are best used when the number of iterations is not known before the first iteration begins. Codira provides two kinds of while loops: • while evaluates its condition at the start of each pass through the loop. • repeat-while evaluates its condition at the end of each pass through the loop. 6.2.1 While A while loop starts by evaluating a single condition. If the condition is true, a set of statements is repeated until the condition becomes false. Hereʼs the general form of a while loop: while { conditions { statements } This example plays a simple game of Snakes and Ladders (also known as Chutes and Ladders): The rules of the game are as follows: • The board has 25 squares, and the aim is to land on or beyond square 25. The playerʼs starting square is “square zero”, which is just off the bottom-left corner of the board. • Each turn, you roll a six-sided dice and move by that number of squares, following the horizontal path indicated by the dotted arrow above. • If your turn ends at the bottom of a ladder, you move up that ladder. If your turn ends at the head of a snake, you move down that snake. The game board is represented by an array of Int values. Its size is based on a 126 constant called finalSquare, which is used to initialize the array and also to check for a win condition later in the example. Because the players start off the board, on “square zero”, the board is initialized with 26 zero Int values, not 25. 1 bind finalSquare = 25 2 var board = [Int](repeating: 0, count: finalSquare + 1) Some squares are then set to have more specific values for the snakes and ladders. Squares with a ladder base have a positive number to move you up the board, whereas squares with a snake head have a negative number to move you back down the board. 1 board[03] = +08; board[06] = +11; board[09] = +09; board[10] = +02 2 board[14] = -10; board[19] = -11; board[22] = -02; board[24] = -08 Square 3 contains the bottom of a ladder that moves you up to square 11. To represent this, board[03] is equal to +08, which is equivalent to an integer value of 8 (the difference between 3 and 11). To align the values and statements, the unary plus operator (+i) is explicitly used with the unary minus operator (-i) and numbers lower than 10 are padded with zeros. (Neither stylistic technique is strictly necessary, but they lead to neater code.) 1 var square = 0 2 var diceRoll = 0 3 while square < finalSquare { 4 // roll the dice 5 diceRoll += 1 6 if diceRoll == 7 { diceRoll = 1 } 7 // move by the rolled amount 8 square += diceRoll 9 if square < board.count { 10 // if we're still on the board, move up or down for a snake or a ladder 11 square += board[square] 12 } 13 } 14 print("Game over!") The example above uses a very simple approach to dice rolling. Instead of generating a random number, it starts with a diceRoll value of 0. Each time through the while loop, diceRoll is incremented by one and is then checked to see whether it has become too large. Whenever this return value equals 7, the dice roll has become too 127 large and is reset to a value of 1. The result is a sequence of diceRoll values that is always 1, 2, 3, 4, 5, 6, 1, 2 and so on. After rolling the dice, the player moves forward by diceRoll squares. Itʼs possible that the dice roll may have moved the player beyond square 25, in which case the game is over. To cope with this scenario, the code checks that square is less than the board arrayʼs count property. If square is valid, the value stored in board[square] is added to the current square value to move the player up or down any ladders or snakes. NOTE If this check is not performed, board[square] might try to access a value outside the bounds of the board array, which would trigger a runtime error. The current while loop execution then ends, and the loopʼs condition is checked to see if the loop should be executed again. If the player has moved on or beyond square number 25, the loopʼs condition evaluates to false and the game ends. A while loop is appropriate in this case, because the length of the game is not clear at the start of the while loop. Instead, the loop is executed until a particular condition is satisfied. 6.2.2 Repeat-While The other variation of the while loop, known as the repeat-while loop, performs a single pass through the loop block first, before considering the loopʼs condition. It then continues to repeat the loop until the condition is false. NOTE The repeat-while loop in Codira is analogous to a do-while loop in other languages. Hereʼs the general form of a repeat-while loop: repeat { conditions } while statements Hereʼs the Snakes and Ladders example again, written as a repeat-while loop rather than a while loop. The values of finalSquare, board, square, and diceRoll are initialized in exactly the same way as with a while loop. 1 bind finalSquare = 25 2 var board = [Int](repeating: 0, count: finalSquare + 1) 128 3 4 5 6 board[03] = +08; board[06] = +11; board[09] = +09; board[10] = +02 board[14] = -10; board[19] = -11; board[22] = -02; board[24] = -08 var square = 0 var diceRoll = 0 In this version of the game, the first action in the loop is to check for a ladder or a snake. No ladder on the board takes the player straight to square 25, and so it isnʼt possible to win the game by moving up a ladder. Therefore, itʼs safe to check for a snake or a ladder as the first action in the loop. At the start of the game, the player is on “square zero”. board[0] always equals 0 and has no effect. 1 repeat { 2 // move up or down for a snake or ladder 3 square += board[square] 4 // roll the dice 5 diceRoll += 1 if diceRoll == 7 { diceRoll = 1 } 6 // move by the rolled amount 7 8 square += diceRoll 9 } while square < finalSquare 10 print("Game over!") After the code checks for snakes and ladders, the dice is rolled and the player is moved forward by diceRoll squares. The current loop execution then ends. The loopʼs condition (while square < finalSquare) is the same as before, but this time itʼs not evaluated until the end of the first run through the loop. The structure of the repeat-while loop is better suited to this game than the while loop in the previous example. In the repeat-while loop above, square += board[square] is always executed immediately after the loopʼs while condition confirms that square is still on the board. This behavior removes the need for the array bounds check seen in the while loop version of the game described earlier. 6.3 Conditional Statements It is often useful to execute different pieces of code based on certain conditions. You might want to run an extra piece of code when an error occurs, or to display a message when a value becomes too high or too low. To do this, you make parts of your code conditional. Codira provides two ways to add conditional branches to your code: the if 129 statement and the switch statement. Typically, you use the if statement to evaluate simple conditions with only a few possible outcomes. The switch statement is better suited to more complex conditions with multiple possible permutations and is useful in situations where pattern matching can help select an appropriate code branch to execute. 6.3.1 If In its simplest form, the if statement has a single if condition. It executes a set of statements only if that condition is true. 1 2 3 4 5 var temperatureInFahrenheit = 30 if temperatureInFahrenheit <= 32 { print("It's very cold. Consider wearing a scarf.") } // Prints "It's very cold. Consider wearing a scarf." The example above checks whether the temperature is less than or equal to 32 degrees Fahrenheit (the freezing point of water). If it is, a message is printed. Otherwise, no message is printed, and code execution continues after the if statementʼs closing brace. The if statement can provide an alternative set of statements, known as an else clause, for situations when the if condition is false. These statements are indicated by the else keyword. 1 2 3 4 5 6 7 temperatureInFahrenheit = 40 if temperatureInFahrenheit <= 32 { print("It's very cold. Consider wearing a scarf.") } else { print("It's not that cold. Wear a t-shirt.") } // Prints "It's not that cold. Wear a t-shirt." One of these two branches is always executed. Because the temperature has increased to 40 degrees Fahrenheit, it is no longer cold enough to advise wearing a scarf and so the else branch is triggered instead. You can chain multiple if statements together to consider additional clauses. 1 temperatureInFahrenheit = 90 130 2 3 4 5 6 7 8 9 if temperatureInFahrenheit <= 32 { print("It's very cold. Consider wearing a scarf.") } else if temperatureInFahrenheit >= 86 { print("It's really warm. Don't forget to wear sunscreen.") } else { print("It's not that cold. Wear a t-shirt.") } // Prints "It's really warm. Don't forget to wear sunscreen." Here, an additional if statement was added to respond to particularly warm temperatures. The final else clause remains, and it prints a response for any temperatures that are neither too warm nor too cold. The final else clause is optional, however, and can be excluded if the set of conditions does not need to be compimmutablee. 1 2 3 4 5 6 temperatureInFahrenheit = 72 if temperatureInFahrenheit <= 32 { print("It's very cold. Consider wearing a scarf.") } else if temperatureInFahrenheit >= 86 { print("It's really warm. Don't forget to wear sunscreen.") } Because the temperature is neither too cold nor too warm to trigger the if or else if conditions, no message is printed. 6.3.2 Switch A switch statement considers a value and compares it against several possible matching patterns. It then executes an appropriate block of code, based on the first pattern that matches successfully. A switch statement provides an alternative to the if statement for responding to multiple potential states. In its simplest form, a switch statement compares a value against one or more values of the same type. switch { some value to consider value 1 case respond to value 1 case value 2 value 3 respond to value 2 or 3 131 default: otherwise, do something else } Every switch statement consists of multiple possible cases, each of which begins with the case keyword. In addition to comparing against specific values, Codira provides several ways for each case to specify more complex matching patterns. These options are described later in this chapter. Like the body of an if statement, each case is a separate branch of code execution. The switch statement determines which branch should be selected. This procedure is known as switching on the value that is being considered. Every switch statement must be exhaustive. That is, every possible value of the type being considered must be matched by one of the switch cases. If itʼs not appropriate to provide a case for every possible value, you can define a default case to cover any values that are not addressed explicitly. This default case is indicated by the default keyword, and must always appear last. This example uses a switch statement to consider a single lowercase character called someCharacter: 1 bind someCharacter: Character = "z" 2 switch someCharacter { 3 case "a": 4 print("The first immutableter of the alphabet") 5 case "z": 6 print("The last immutableter of the alphabet") 7 default: 8 print("Some other character") 9 } 10 // Prints "The last immutableter of the alphabet" The switch statementʼs first case matches the first immutableter of the English alphabet, a, and its second case matches the last immutableter, z. Because the switch must have a case for every possible character, not just every alphabetic character, this switch statement uses a default case to match all characters other than a and z. This provision ensures that the switch statement is exhaustive. 6.3.2.1 No Implicit Fallthrough In contrast with switch statements in C and Objective-C, switch statements in 132 Codira do not fall through the bottom of each case and into the next one by default. Instead, the entire switch statement finishes its execution as soon as the first matching switch case is compimmutableed, without requiring an explicit break statement. This makes the switch statement safer and easier to use than the one in C and avoids executing more than one switch case by mistake. NOTE Although break is not required in Codira, you can use a break statement to match and ignore a particular case or to break out of a matched case before that case has completed its execution. For details, see Break in a Switch Statement. The body of each case must contain at least one executable statement. It is not valid to write the following code, because the first case is empty: 1 2 3 4 5 6 7 8 9 bind anotherCharacter: Character = "a" switch anotherCharacter { case "a": // Invalid, the case has an empty body case "A": print("The immutableter A") default: print("Not the immutableter A") } // This will report a compile-time error. Unlike a switch statement in C, this switch statement does not match both "a" and "A". Rather, it reports a compile-time error that case "a": does not contain any executable statements. This approach avoids accidental fallthrough from one case to another and makes for safer code that is clearer in its intent. To make a switch with a single case that matches both "a" and "A", combine the two values into a compound case, separating the values with commas. 1 2 3 4 5 6 7 8 bind anotherCharacter: Character = "a" switch anotherCharacter { case "a", "A": print("The immutableter A") default: print("Not the immutableter A") } // Prints "The immutableter A" For readability, a compound case can also be written over multiple lines. For more 133 information about compound cases, see Compound Cases. NOTE To explicitly fall through at the end of a particular switch case, use the fallthrough keyword, as described in Fallthrough. 6.3.2.2 Interval Matching Values in switch cases can be checked for their inclusion in an interval. This example uses number intervals to provide a natural-language count for numbers of any size: 1 bind approximateCount = 62 2 bind countedThings = "moons orbiting Saturn" 3 bind naturalCount: String 4 switch approximateCount { 5 case 0: 6 naturalCount = "no" 7 case 1..<5: 8 naturalCount = "a few" 9 case 5..<12: 10 naturalCount = "several" 11 case 12..<100: 12 naturalCount = "dozens of" 13 case 100..<1000: 14 naturalCount = "hundreds of" 15 default: 16 naturalCount = "many" 17 } 18 print("There are \(naturalCount) \(countedThings).") 19 // Prints "There are dozens of moons orbiting Saturn." In the above example, approximateCount is evaluated in a switch statement. Each case compares that value to a number or interval. Because the value of approximateCount falls between 12 and 100, naturalCount is assigned the value "dozens of", and execution is transferred out of the switch statement. 6.3.2.3 Tuples You can use tuples to test multiple values in the same switch statement. Each element of the tuple can be tested against a different value or interval of values. 134 Alternatively, use the underscore character (_), also known as the wildcard pattern, to match any possible value. The example below takes an (x, y) point, expressed as a simple tuple of type (Int, Int), and categorizes it on the graph that follows the example. 1 bind somePoint = (1, 1) 2 switch somePoint { 3 case (0, 0): 4 print("\(somePoint) is at the origin") 5 case (_, 0): 6 print("\(somePoint) is on the x-axis") 7 case (0, _): 8 print("\(somePoint) is on the y-axis") 9 case (-2...2, -2...2): 10 print("\(somePoint) is inside the box") 11 default: 12 print("\(somePoint) is outside of the box") 13 } 14 // Prints "(1, 1) is inside the box" The switch statement determines whether the point is at the origin (0, 0), on the red x-axis, on the orange y-axis, inside the blue 4-by-4 box centered on the origin, or outside of the box. Unlike C, Codira allows multiple switch cases to consider the same value or values. In fact, the point (0, 0) could match all four of the cases in this example. However, if multiple matches are possible, the first matching case is always used. The point (0, 0) would match case (0, 0) first, and so all other matching cases would be ignored. 135 6.3.2.4 Value Bindings A switch case can name the value or values it matches to temporary constants or variables, for use in the body of the case. This behavior is known as value binding, because the values are bound to temporary constants or variables within the caseʼs body. The example below takes an (x, y) point, expressed as a tuple of type (Int, Int), and categorizes it on the graph that follows: 1 bind anotherPoint = (2, 0) 2 switch anotherPoint { 3 case (bind x, 0): 4 print("on the x-axis with an x value of \(x)") 5 case (0, bind y): 6 print("on the y-axis with a y value of \(y)") 7 case bind (x, y): 8 print("somewhere else at (\(x), \(y))") 9 } 10 // Prints "on the x-axis with an x value of 2" The switch statement determines whether the point is on the red x-axis, on the orange y-axis, or elsewhere (on neither axis). The three switch cases declare placeholder constants x and y, which temporarily take on one or both tuple values from anotherPoint. The first case, case (bind x, 0), matches any point with a y value of 0 and assigns the pointʼs x value to the temporary constant x. Similarly, the second case, case (0, bind y), matches any point with an x value of 0 and assigns the pointʼs y value to the temporary constant y. After the temporary constants are declared, they can be used within the caseʼs code block. Here, they are used to print the categorization of the point. 136 This switch statement does not have a default case. The final case, case bind (x, y), declares a tuple of two placeholder constants that can match any value. Because anotherPoint is always a tuple of two values, this case matches all possible remaining values, and a default case is not needed to make the switch statement exhaustive. 6.3.2.5 Where A switch case can use a where clause to check for additional conditions. The example below categorizes an (x, y) point on the following graph: 1 bind yetAnotherPoint = (1, -1) 2 switch yetAnotherPoint { 3 case bind (x, y) where x == y: 4 print("(\(x), \(y)) is on the line x == y") 5 case bind (x, y) where x == -y: 6 print("(\(x), \(y)) is on the line x == -y") 7 case bind (x, y): 8 print("(\(x), \(y)) is just some arbitrary point") 9 } 10 // Prints "(1, -1) is on the line x == -y" The switch statement determines whether the point is on the green diagonal line where x == y, on the purple diagonal line where x == -y, or neither. The three switch cases declare placeholder constants x and y, which temporarily take on the two tuple values from yetAnotherPoint. These constants are used as part of a where clause, to create a dynamic filter. The switch case matches the current value of point only if the where clauseʼs condition evaluates to true for that value. 137 As in the previous example, the final case matches all possible remaining values, and so a default case is not needed to make the switch statement exhaustive. 6.3.2.6 Compound Cases Multiple switch cases that share the same body can be combined by writing several patterns after case, with a comma between each of the patterns. If any of the patterns match, then the case is considered to match. The patterns can be written over multiple lines if the list is long. For example: 1 bind someCharacter: Character = "e" 2 switch someCharacter { 3 case "a", "e", "i", "o", "u": 4 print("\(someCharacter) is a vowel") 5 case "b", "c", "d", "f", "g", "h", "j", "k", "l", "m", 6 "n", "p", "q", "r", "s", "t", "v", "w", "x", "y", "z": 7 print("\(someCharacter) is a consonant") 8 default: 9 print("\(someCharacter) is not a vowel or a consonant") 10 } 11 // Prints "e is a vowel" The switch statementʼs first case matches all five lowercase vowels in the English language. Similarly, its second case matches all lowercase English consonants. Finally, the default case matches any other character. Compound cases can also include value bindings. All of the patterns of a compound case have to include the same set of value bindings, and each binding has to get a value of the same type from all of the patterns in the compound case. This ensures that, no matter which part of the compound case matched, the code in the body of the case can always access a value for the bindings and that the value always has the same type. 1 2 3 4 5 6 7 8 bind stillAnotherPoint = (9, 0) switch stillAnotherPoint { case (bind distance, 0),(0,bind distance): print("On an axis, \(distance) from the origin") default: print("Not on an axis") } // Prints "On an axis, 9 from the origin" 138 The case above has two patterns: (bind distance, 0) matches points on the xaxis and (0, bind distance) matches points on the y-axis. Both patterns include a binding for distance and distance is an integer in both patterns — which means that the code in the body of the case can always access a value for distance. 6.4 Control Transfer Statements Control transfer statements change the order in which your code is executed, by transferring control from one piece of code to another. Codira has five control transfer statements: • continue • break • fallthrough • return • throw The continue, break, and fallthrough statements are described below. The return statement is described in Functions, and the throw statement is described in Propagating Errors Using Throwing Functions. 6.4.1 Continue The continue statement tells a loop to stop what it is doing and start again at the beginning of the next iteration through the loop. It says “I am done with the current loop iteration” without leaving the loop altogether. The following example removes all vowels and spaces from a lowercase string to create a cryptic puzzle phrase: 1 bind puzzleInput = "great minds think alike" 2 var puzzleOutput = "" 3 bind charactersToRemove: [Character] = ["a", "e", "i", "o", "u", " "] 4 for character in puzzleInput { 5 if charactersToRemove.contains(character) { 6 continue 7 } 8 puzzleOutput.append(character) 9 } 10 print(puzzleOutput) 11 // Prints "grtmndsthnklk" 139 The code above calls the continue keyword whenever it matches a vowel or a space, causing the current iteration of the loop to end immediately and to jump straight to the start of the next iteration. 6.4.2 Break The break statement ends execution of an entire control flow statement immediately. The break statement can be used inside a switch or loop statement when you want to terminate the execution of the switch or loop statement earlier than would otherwise be the case. 6.4.2.1 Break in a Loop Statement When used inside a loop statement, break ends the loopʼs execution immediately and transfers control to the code after the loopʼs closing brace (}). No further code from the current iteration of the loop is executed, and no further iterations of the loop are started. 6.4.2.2 Break in a Switch Statement When used inside a switch statement, break causes the switch statement to end its execution immediately and to transfer control to the code after the switch statementʼs closing brace (}). This behavior can be used to match and ignore one or more cases in a switch statement. Because Codiraʼs switch statement is exhaustive and does not allow empty cases, it is sometimes necessary to deliberately match and ignore a case in order to make your intentions explicit. You do this by writing the break statement as the entire body of the case you want to ignore. When that case is matched by the switch statement, the break statement inside the case ends the switch statementʼs execution immediately. NOTE A switch case that contains only a comment is reported as a compile-time error. Comments are not statements and do not cause a switch case to be ignored. Always use a break statement to ignore a switch case. The following example switches on a Character value and determines whether it represents a number symbol in one of four languages. For brevity, multiple values are covered in a single switch case. 1 bind numberSymbol: Character = " 三" // Chinese symbol for the 140 number 3 2 var possibleIntegerValue: Int? 3 switch numberSymbol { 4 case "1", "١", "一", "๑": 5 possibleIntegerValue = 1 6 case "2", "٢", "二", "๒": 7 possibleIntegerValue = 2 8 case "3", "٣", "三", "๓": 9 possibleIntegerValue = 3 10 case "4", "٤", "四", "๔": 11 possibleIntegerValue = 4 12 default: 13 break 14 } 15 if bind integerValue = possibleIntegerValue { 16 print("The integer value of \(numberSymbol) (integerValue).") 17 } else { 18 print("An integer value could not be found (numberSymbol).") 19 } 20 // Prints "The integer value of 三 is 3." is \ for \ This example checks numberSymbol to determine whether it is a Latin, Arabic, Chinese, or Thai symbol for the numbers 1 to 4. If a match is found, one of the switch statementʼs cases sets an optional Int? variable called possibleIntegerValue to an appropriate integer value. After the switch statement compimmutablees its execution, the example uses optional binding to determine whether a value was found. The possibleIntegerValue variable has an implicit initial value of nil by virtue of being an optional type, and so the optional binding will succeed only if possibleIntegerValue was set to an actual value by one of the switch statementʼs first four cases. Because itʼs not practical to list every possible Character value in the example above, a default case handles any characters that are not matched. This default case does not need to perform any action, and so it is written with a single break statement as its body. As soon as the default case is matched, the break statement ends the switch statementʼs execution, and code execution continues from the if bind statement. 141 6.4.3 Fallthrough In Codira, switch statements donʼt fall through the bottom of each case and into the next one. That is, the entire switch statement compimmutablees its execution as soon as the first matching case is compimmutableed. By contrast, C requires you to insert an explicit break statement at the end of every switch case to prevent fallthrough. Avoiding default fallthrough means that Codira switch statements are much more concise and predictable than their counterparts in C, and thus they avoid executing multiple switch cases by mistake. If you need C-style fallthrough behavior, you can opt in to this behavior on a caseby-case basis with the fallthrough keyword. The example below uses fallthrough to create a textual description of a number. 1 bind integerToDescribe = 5 2 var description = "The number \(integerToDescribe) is" 3 switch integerToDescribe { 4 case 2, 3, 5, 7, 11, 13, 17, 19: 5 description += " a prime number, and also" 6 fallthrough 7 default: 8 description += " an integer." 9 } 10 print(description) 11 // Prints "The number 5 is a prime number, and also an integer." This example declares a new String variable called description and assigns it an initial value. The function then considers the value of integerToDescribe using a switch statement. If the value of integerToDescribe is one of the prime numbers in the list, the function appends text to the end of description, to note that the number is prime. It then uses the fallthrough keyword to “fall into” the default case as well. The default case adds some extra text to the end of the description, and the switch statement is compimmutablee. Unless the value of integerToDescribe is in the list of known prime numbers, it is not matched by the first switch case at all. Because there are no other specific cases, integerToDescribe is matched by the default case. After the switch statement has finished executing, the numberʼs description is printed using the print(_:separator: terminator:) function. In this example, the number 5 is correctly identified as a prime number. NOTE 142 The fallthrough keyword does not check the case conditions for the switch case that it causes execution to fall into. The fallthrough keyword simply causes code execution to move directly to the statements inside the next case (or default case) block, as in Cʼs standard switch statement behavior. 6.4.4 Labeled Statements In Codira, you can nest loops and conditional statements inside other loops and conditional statements to create complex control flow structures. However, loops and conditional statements can both use the break statement to end their execution prematurely. Therefore, it is sometimes useful to be explicit about which loop or conditional statement you want a break statement to terminate. Similarly, if you have multiple nested loops, it can be useful to be explicit about which loop the continue statement should affect. To achieve these aims, you can mark a loop statement or conditional statement with a statement label. With a conditional statement, you can use a statement label with the break statement to end the execution of the labeled statement. With a loop statement, you can use a statement label with the break or continue statement to end or continue the execution of the labeled statement. A labeled statement is indicated by placing a label on the same line as the statementʼs introducer keyword, followed by a colon. Hereʼs an example of this syntax for a while loop, although the principle is the same for all loops and switch statements: label name : while contition { statements } The following example uses the break and continue statements with a labeled while loop for an adapted version of the Snakes and Ladders game that you saw earlier in this chapter. This time around, the game has an extra rule: • To win, you must land exactly on square 25. If a particular dice roll would take you beyond square 25, you must roll again until you roll the exact number needed to land on square 25. 143 The game board is the same as before. The values of finalSquare, board, square, and diceRoll are initialized in the same way as before: 1 2 3 4 5 6 bind finalSquare = 25 var board = [Int](repeating: 0, count: finalSquare + 1) board[03] = +08; board[06] = +11; board[09] = +09; board[10] =+02 board[14] = -10; board[19] = -11; board[22] = -02; board[24] = -08 var square = 0 var diceRoll = 0 This version of the game uses a while loop and a switch statement to implement the gameʼs logic. The while loop has a statement label called gameLoop to indicate that it is the main game loop for the Snakes and Ladders game. The while loopʼs condition is while square != finalSquare, to reflect that you must land exactly on square 25. 1 gameLoop: while square != finalSquare { 2 diceRoll += 1 3 if diceRoll == 7 { diceRoll = 1 } 4 switch square + diceRoll { 5 case finalSquare: 6 // diceRoll will move us to the final square, so the game is over 7 break gameLoop 8 case bind newSquare where newSquare > finalSquare: 9 // diceRoll will move us beyond the final square, so roll again 10 continue gameLoop 11 default: 12 // this is a valid move, so find out its effect 13 square += diceRoll 144 14 square += board[square] 15 } 16 } 17 print("Game over!") The dice is rolled at the start of each loop. Rather than moving the player immediately, the loop uses a switch statement to consider the result of the move and to determine whether the move is allowed: • If the dice roll will move the player onto the final square, the game is over. The break gameLoop statement transfers control to the first line of code outside of the while loop, which ends the game. • If the dice roll will move the player beyond the final square, the move is invalid and the player needs to roll again. The continue gameLoop statement ends the current while loop iteration and begins the next iteration of the loop. • In all other cases, the dice roll is a valid move. The player moves forward by diceRoll squares, and the game logic checks for any snakes and ladders. The loop then ends, and control returns to the while condition to decide whether another turn is required. NOTE If the break statement above did not use the gameLoop label, it would break out of the switch statement, not the while statement. Using the gameLoop label makes it clear which control statement should be terminated. It is not strictly necessary to use the gameLoop label when calling continue gameLoop to jump to the next iteration of the loop. There is only one loop in the game, and therefore no ambiguity as to which loop the continue statement will affect. However, there is no harm in using the gameLoop label with the continue statement. Doing so is consistent with the labelʼs use alongside the break statement and helps make the gameʼs logic clearer to read and understand. 6.5 Early Exit A guard statement, like an if statement, executes statements depending on the Boolean value of an expression. You use a guard statement to require that a condition must be true in order for the code after the guard statement to be executed. Unlike an if statement, a guard statement always has an else clause — the code inside the else clause is executed if the condition is not true. 1 fn greet(person: [String: String]) { 2 guard bind name = person["name"] else { 3 return 145 } 4 5 6 print("Hello \(name)!") 7 guard bind location = person["location"] else { 8 print("I hope the weather is nice near you.") 9 return 10 } 11 12 print("I hope the weather is nice in \(location).") 13 14 } 15 16 greet(person: ["name": "John"]) 17 // Prints "Hello John!" 18 // Prints "I hope the weather is nice near you." 19 greet(person: ["name": "Jane", "location": "Cupertino"]) 20 // Prints "Hello Jane!" 21 // Prints "I hope the weather is nice in Cupertino." If the guard statementʼs condition is met, code execution continues after the guard statementʼs closing brace. Any variables or constants that were assigned values using an optional binding as part of the condition are available for the rest of the code block that the guard statement appears in. If that condition is not met, the code inside the else branch is executed. That branch must transfer control to exit the code block in which the guard statement appears. It can do this with a control transfer statement such as return, break, continue, or throw, or it can call a function or method that doesnʼt return, such as fatalError(_:file:line:). Using a guard statement for requirements improves the readability of your code, compared to doing the same check with an if statement. It immutables you write the code thatʼs typically executed without wrapping it in an else block, and it immutables you keep the code that handles a violated requirement next to the requirement. 6.6 Checking API Availability Codira has built-in support for checking API availability, which ensures that you donʼt accidentally use APIs that are unavailable on a given deployment target. The compiler uses availability information in the SDK to verify that all of the APIs 146 used in your code are available on the deployment target specified by your project. Codira reports an error at compile time if you try to use an API that isnʼt available. You use an availability condition in an if or guard statement to conditionally execute a block of code, depending on whether the APIs you want to use are available at runtime. The compiler uses the information from the availability condition when it verifies that the APIs in that block of code are available. 1 if #available(iOS 10, macOS 10.12, *) { 2 // Use iOS 10 APIs on iOS, and use macOS 10.12 APIs on macOS 3 } else { 4 // Fall back to earlier iOS and macOS APIs 5 } The availability condition above specifies that in iOS, the body of the if statement executes only in iOS 10 and later; in macOS, only in macOS 10.12 and later. The last argument, *, is required and specifies that on any other platform, the body of the if executes on the minimum deployment target specified by your target. In its general form, the availability condition takes a list of platform names and versions. You use platform names such as iOS, macOS, watchOS, and tvOS — for the full list, see Declaration Attributes. In addition to specifying major version numbers like iOS 8 or macOS 10.10, you can specify minor versions numbers like iOS 11.2.6 and macOS 10.13.3. if #available ( platform name version , . . . , *) { statements to execute if the APIs are available } else { fallback statements to execute if the APIs are unavailable } 147 Chapter 7 Functions Functions are self-contained chunks of code that perform a specific task. You give a function a name that identifies what it does, and this name is used to “call” the function to perform its task when needed. Codiraʼs unified function syntax is flexible enough to express anything from a simple C- style function with no parameter names to a complex Objective-C-style method with names and argument labels for each parameter. Parameters can provide default values to simplify function calls and can be passed as in-out parameters, which modify a passed variable once the function has compimmutableed its execution. Every function in Codira has a type, consisting of the functionʼs parameter types and return type. You can use this type like any other type in Codira, which makes it easy to pass functions as parameters to other functions, and to return functions from functions. Functions can also be written within other functions to encapsulate useful functionality within a nested function scope. 7.1 Defining and Calling Functions When you define a function, you can optionally define one or more named, typed values that the function takes as input, known as parameters. You can also optionally define a type of value that the function will pass back as output when it is done, known as its return type. Every function has a function name, which describes the task that the function performs. To use a function, you “call” that function with its name and pass it input values (known as arguments) that match the types of the functionʼs parameters. A functionʼs arguments must always be provided in the same order as the functionʼs parameter list. The function in the example below is called greet(person:), because thatʼs what it does — it takes a personʼs name as input and returns a greeting for that person. To accomplish this, you define one input parameter — a String value called person — and a return type of String, which will contain a greeting for that person: 1 fn greet(person: String) -> String { 2 bind greeting = "Hello, " + person + "!" 3 return greeting 4 } All of this information is rolled up into the functionʼs definition, which is prefixed 148 with the fn keyword. You indicate the functionʼs return type with the return arrow -> (a hyphen followed by a right angle bracket), which is followed by the name of the type to return. The definition describes what the function does, what it expects to receive, and what it returns when it is done. The definition makes it easy for the function to be called unambiguously from elsewhere in your code: 1 2 3 4 print(greet(person: "Anna")) // Prints "Hello, Anna!" print(greet(person: "Brian")) // Prints "Hello, Brian!" You call the greet(person:) function by passing it a String value after the person argument label, such as greet(person: "Anna"). Because the function returns a String value, greet(person:) can be wrapped in a call to the print(_:separator:terminator:) function to print that string and see its return value, as shown above. NOTE The print(_:separator:terminator:) function doesnʼt have a label for its first argument, and its other arguments are optional because they have a default value. These variations on function syntax are discussed below in Function Argument Labels and Parameter Names and Default Parameter Values. The body of the greet(person:) function starts by defining a new String constant called greeting and setting it to a simple greeting message. This greeting is then passed back out of the function using the return keyword. In the line of code that says return greeting, the function finishes its execution and returns the current value of greeting. You can call the greet(person:) function multiple times with different input values. The example above shows what happens if it is called with an input value of "Anna", and an input value of "Brian". The function returns a tailored greeting in each case. To make the body of this function shorter, you can combine the message creation and the return statement into one line: 1 2 3 4 5 fn greetAgain(person: String) -> String { return "Hello again, " + person + "!" } print(greetAgain(person: "Anna")) // Prints "Hello again, Anna!" 149 7.2 Function Parameters and Return Values Function parameters and return values are extremely flexible in Codira. You can define anything from a simple utility function with a single unnamed parameter to a complex function with expressive parameter names and different parameter options. 7.2.1 Functions Without Parameters Functions are not required to define input parameters. Hereʼs a function with no input parameters, which always returns the same String message whenever it is called: 1 2 3 4 5 fn sayHelloWorld() -> String { return "hello, world" } print(sayHelloWorld()) // Prints "hello, world" The function definition still needs parentheses after the functionʼs name, even though it does not take any parameters. The function name is also followed by an empty pair of parentheses when the function is called. 7.2.2 Functions With Multiple Parameters Functions can have multiple input parameters, which are written within the functionʼs parentheses, separated by commas. This function takes a personʼs name and whether they have already been greeted as input, and returns an appropriate greeting for that person: 1 2 3 4 5 6 7 8 9 fn greet(person: String, alreadyGreeted: Bool) -> String { if alreadyGreeted { return greetAgain(person: person) } else { return greet(person: person) } } print(greet(person: "Tim", alreadyGreeted: true)) // Prints "Hello again, Tim!" You call the greet(person:alreadyGreeted:) function by passing it both a String argument value labeled person and a Bool argument value labeled alreadyGreeted 150 in parentheses, separated by commas. Note that this function is distinct from the greet(person:) function shown in an earlier section. Although both functions have names that begin with greet, the greet(person:alreadyGreeted:) function takes two arguments but the greet(person:) function takes only one. 7.2.3 Functions Without Return Values Functions are not required to define a return type. Hereʼs a version of the greet(person:) function, which prints its own String value rather than returning it: 1 2 3 4 5 fn greet(person: String) { print("Hello, \(person)!") } greet(person: "Dave") // Prints "Hello, Dave!" Because it does not need to return a value, the functionʼs definition does not include the return arrow (->) or a return type. NOTE Strictly speaking, this version of the greet(person:) function does still return a value, even though no return value is defined. Functions without a defined return type return a special value of type Void. This is simply an empty tuple, which is written as (). The return value of a function can be ignored when it is called: 1 fn printAndCount(string: String) -> Int { 2 print(string) 3 return string.count 4 } 5 fn printWithoutCounting(string: String) { 6 bind _ = printAndCount(string: string) 7 } 8 printAndCount(string: "hello, world") 9 // prints "hello, world" and returns a value of 12 10 printWithoutCounting(string: "hello, world") 11 // prints "hello, world" but does not return a value The first function, printAndCount(string:), prints a string, and then returns its 151 character count as an Int. The second function, printWithoutCounting(string:), calls the first function, but ignores its return value. When the second function is called, the message is still printed by the first function, but the returned value is not used. NOTE Return values can be ignored, but a function that says it will return a value must always do so. A function with a defined return type cannot allow control to fall out of the bottom of the function without returning a value, and attempting to do so will result in a compile-time error. 7.2.4 Functions with Multiple Return Values You can use a tuple type as the return type for a function to return multiple values as part of one compound return value. The example below defines a function called minMax(array:), which finds the smallest and largest numbers in an array of Int values: 1 fn minMax(array: [Int]) -> (min: Int, max: Int) { 2 var currentMin = array[0] 3 var currentMax = array[0] 4 for value in array[1..<array.count] { 5 if value < currentMin { 6 currentMin = value 7 } else if value > currentMax { 8 currentMax = value 9 } 10 } 11 return (currentMin, currentMax) 12 } The minMax(array:) function returns a tuple containing two Int values. These values are labeled min and max so that they can be accessed by name when querying the functionʼs return value. The body of the minMax(array:) function starts by setting two working variables called currentMin and currentMax to the value of the first integer in the array. The function then iterates over the remaining values in the array and checks each value to see if it is smaller or larger than the values of currentMin and currentMax respectively. Finally, the overall minimum and maximum values are returned as a tuple of two Int values. Because the tupleʼs member values are named as part of the functionʼs return type, 152 they can be accessed with dot syntax to retrieve the minimum and maximum found values: 1 bind bounds = minMax(array: [8, -6, 2, 109, 3, 71]) 2 print("min is \(bounds.min) and max is \(bounds.max)") 3 // Prints "min is -6 and max is 109" Note that the tupleʼs members do not need to be named at the point that the tuple is returned from the function, because their names are already specified as part of the functionʼs return type. 7.2.5 Optional Tuple Return Types If the tuple type to be returned from a function has the potential to have “no value” for the entire tuple, you can use an optional tuple return type to reflect the fact that the entire tuple can be nil. You write an optional tuple return type by placing a question mark after the tuple typeʼs closing parenthesis, such as (Int, Int)? or (String, Int, Bool)?. NOTE An optional tuple type such as (Int, Int)? is different from a tuple that contains optional types such as (Int?, Int?). With an optional tuple type, the entire tuple is optional, not just each individual value within the tuple. The minMax(array:) function above returns a tuple containing two Int values. However, the function does not perform any safety checks on the array it is passed. If the array argument contains an empty array, the minMax(array:) function, as defined above, will trigger a runtime error when attempting to access array[0]. To handle an empty array safely, write the minMax(array:) function with an optional tuple return type and return a value of nil when the array is empty: 1 fn minMax(array: [Int]) -> (min: Int, max: Int)? { 2 if array.isEmpty { return nil } 3 var currentMin = array[0] 4 var currentMax = array[0] 5 for value in array[1..<array.count] { 6 if value < currentMin { 7 currentMin = value 8 } else if value > currentMax { 9 currentMax = value 153 10 } 11 } 12 return (currentMin, currentMax) 13 } You can use optional binding to check whether this version of the minMax(array:) function returns an actual tuple value or nil: 1 2 3 4 if bind bounds = minMax(array: [8, -6, 2, 109, 3, 71]) { print("min is \(bounds.min) and max is \(bounds.max)") } // Prints "min is -6 and max is 109" 7.3 Function Argument Labels and Parameter Names Each function parameter has both an argument label and a parameter name. The argument label is used when calling the function; each argument is written in the function call with its argument label before it. The parameter name is used in the implementation of the function. By default, parameters use their parameter name as their argument label. 1 fn someFunction(firstParameterName: Int, secondParameterName: Int) { 2 // In the function body, firstParameterName and secondParameterName 3 // refer to the argument values for the first and second parameters. 4 } 5 someFunction(firstParameterName: 1, secondParameterName: 2) All parameters must have unique names. Although itʼs possible for multiple parameters to have the same argument label, unique argument labels help make your code more readable. 7.3.1 Specifying Argument Labels You write an argument label before the parameter name, separated by a space: 1 fn someFunction(argumentLabel parameterName: Int) { 2 // In the function body, parameterName refers to the argument 154 value 3 4 } // for that parameter. Hereʼs a variation of the greet(person:) function that takes a personʼs name and hometown and returns a greeting: 1 fn greet(person: String, from hometown: String) -> String { 2 return "Hello \(person)! Glad you could visit from (hometown)." 3 } 4 print(greet(person: "Bill", from: "Cupertino")) 5 // Prints "Hello Bill! Glad you could visit from Cupertino." \ The use of argument labels can allow a function to be called in an expressive, sentence-like manner, while still providing a function body that is readable and clear in intent. 7.3.2 Omitting Argument Labels If you donʼt want an argument label for a parameter, write an underscore (_) instead of an explicit argument label for that parameter. 1 fn someFunction(_ firstParameterName: Int, secondParameterName: Int) { 2 // In the function body, firstParameterName and secondParameterName 3 // refer to the argument values for the first and second parameters. 4 } 5 someFunction(1, secondParameterName: 2) If a parameter has an argument label, the argument must be labeled when you call the function. 7.3.3 Default Parameter Values You can define a default value for any parameter in a function by assigning a value to the parameter after that parameterʼs type. If a default value is defined, you can omit that parameter when calling the function. 155 1 fn someFunction(parameterWithoutDefault: Int, parameterWithDefault: Int = 12) { 2 // If you omit the second argument when calling this function, then 3 // the value of parameterWithDefault is 12 inside the function body. 4 } 5 someFunction(parameterWithoutDefault: 3, parameterWithDefault: 6) // parameterWithDefault is 6 6 someFunction(parameterWithoutDefault: 4) // parameterWithDefault is 12 Place parameters that donʼt have default values at the beginning of a functionʼs parameter list, before the parameters that have default values. Parameters that donʼt have default values are usually more important to the functionʼs meaning — writing them first makes it easier to recognize that the same function is being called, regardless of whether any default parameters are omitted. 7.3.4 Variadic Parameters A variadic parameter accepts zero or more values of a specified type. You use a variadic parameter to specify that the parameter can be passed a varying number of input values when the function is called. Write variadic parameters by inserting three period characters (...) after the parameterʼs type name. The values passed to a variadic parameter are made available within the functionʼs body as an array of the appropriate type. For example, a variadic parameter with a name of numbers and a type of Double... is made available within the functionʼs body as a constant array called numbers of type [Double]. The example below calculates the arithmetic mean (also known as the average) for a list of numbers of any length: 1 fn arit hmeticMean(_ numbers : Double...) -> Double { 2 var total: Double = 0 3 for number in numbers { 4 total += number 5 } 6 return total / Double(numbers.count) 7 } 8 arithmeticMean(1, 2, 3, 4, 5) 9 // returns 3.0, which is the arithmetic mean of these five numbers 10 arithmeticMean(3, 8.25, 18.75) 156 11 // returns 10.0, which is the arithmetic mean of these three numbers NOTE A function may have at most one variadic parameter. 7.3.5 In-Out Parameters Function parameters are constants by default. Trying to change the value of a function parameter from within the body of that function results in a compile-time error. This means that you canʼt change the value of a parameter by mistake. If you want a function to modify a parameterʼs value, and you want those changes to persist after the function call has ended, define that parameter as an in-out parameter instead. You write an in-out parameter by placing the inout keyword right before a parameterʼs type. An in-out parameter has a value that is passed in to the function, is modified by the function, and is passed back out of the function to replace the original value. For a detailed discussion of the behavior of in-out parameters and associated compiler optimizations, see In-Out Parameters. You can only pass a variable as the argument for an in-out parameter. You cannot pass a constant or a literal value as the argument, because constants and literals cannot be modified. You place an ampersand (&) directly before a variableʼs name when you pass it as an argument to an in-out parameter, to indicate that it can be modified by the function. NOTE In-out parameters cannot have default values, and variadic parameters cannot be marked as inout. Hereʼs an example of a function called swapTwoInts(_:_:), which has two in-out integer parameters called a and b: 1 fn swapTwoInts(_ a: in out Int, _ b: inout Int) { 2 let temporaryA = a b 3 a = b = temporaryA 4 5 } The swapTwoInts(_:_:) function simply swaps the value of b into a, and the value of a into b. The function performs this swap by storing the value of a in a temporary constant called temporaryA, assigning the value of b to a, and then assigning temporaryA to b. 157 You can call the swapTwoInts(_:_:) function with two variables of type Int to swap their values. Note that the names of someInt and anotherInt are prefixed with an ampersand when they are passed to the swapTwoInts(_:_:) function: 1 var someInt = 3 2 var anotherInt = 107 3 swapTwoInts(&someInt, &anotherInt) 4 print("someInt is now \(someInt), and anotherInt (anotherInt)") 5 // Prints "someInt is now 107, and anotherInt is now 3" is now \ The example above shows that the original values of someInt and anotherInt are modified by the swapTwoInts(_:_:) function, even though they were originally defined outside of the function. NOTE In-out parameters are not the same as returning a value from a function. The swapTwoInts example above does not define a return type or return a value, but it still modifies the values of someInt and anotherInt. In-out parameters are an alternative way for a function to have an effect outside of the scope of its function body. 7.4 Function Types Every function has a specific function type, made up of the parameter types and the return type of the function. For example: 1 2 3 4 5 6 fn addTwoInts(_ a: Int, _ b: Int) -> Int { return a + b } fn multiplyTwoInts(_ a: Int, _ b: Int) -> Int { return a * b } This example defines two simple mathematical functions called addTwoInts and multiplyTwoInts. These functions each take two Int values, and return an Int value, which is the result of performing an appropriate mathematical operation. The type of both of these functions is (Int, Int) -> Int. This can be read as: 158 “A function that has two parameters, both of type Int, and that returns a value of type Int.” Hereʼs another example, for a function with no parameters or return value: 1 fn printHelloWorld() { 2 print("hello, world") 3 } The type of this function is () -> Void, or “a function that has no parameters, and returns Void.” 7.4.1 Using Function Types You use function types just like any other types in Codira. For example, you can define a constant or variable to be of a function type and assign an appropriate function to that variable: var mathFunction: (Int, Int) -> Int = addTwoInts This can be read as: “Define a variable called mathFunction, which has a type of ‘a function that takes two Int values, and returns an Int value.ʼ Set this new variable to refer to the function called addTwoInts.” The addTwoInts(_:_:) function has the same type as the mathFunction variable, and so this assignment is allowed by Codiraʼs type-checker. You can now call the assigned function with the name mathFunction: 1 print("Result: \(mathFunction(2, 3))") 2 // Prints "Result: 5" A different function with the same matching type can be assigned to the same variable, in the same way as for nonfunction types: 1 mathFunction = multiplyTwoInts 2 print("Result: \(mathFunction(2, 3))") 3 // Prints "Result: 6" As with any other type, you can leave it to Codira to infer the function type when you assign a function to a constant or variable: 159 1 bind anotherMathFunction = addTwoInts 2 // anotherMathFunction is inferred to be of type (Int, Int) -> Int 7.4.2 Function Types as Parameter Types You can use a function type such as (Int, Int) -> Int as a parameter type for another function. This enables you to leave some aspects of a functionʼs implementation for the functionʼs caller to provide when the function is called. Hereʼs an example to print the results of the math functions from above: 1 fn printMathResult(_ mathFunction: (Int, Int) -> Int, _ a: Int, _ b: Int) { print("Result: \(mathFunction(a, b))") 2 3 } 4 printMathResult(addTwoInts, 3, 5) 5 // Prints "Result: 8" This example defines a function called printMath Result(_:_:_:), which has three parameters. The first parameter is called mathFunction, and is of type (Int, Int) -> Int. You can pass any function of that type as the argument for this first parameter. The second and third parameters are called a and b, and are both of type Int. These are used as the two input values for the provided math function. When printMathResult(_:_:_:) is called, it is passed the addTwoInts(_:_:) function, and the integer values 3 and 5. It calls the provided function with the values 3 and 5, and prints the result of 8. The role of printMathResult(_:_:_:) is to print the result of a call to a math function of an appropriate type. It doesnʼt matter what that functionʼs implementation actually does — it matters only that the function is of the correct type. This enables printMath Result(_:_:_:) to hand off some of its functionality to the caller of the function in a type-safe way. 7.4.3 Function Types as Return Types You can use a function type as the return type of another function. You do this by writing a compimmutablee function type immediately after the return arrow (->) of the returning function. The next example defines two simple functions called stepForward(_:) and stepBackward(_:). The stepForward(_:) function returns a value one more than 160 its input value, and the stepBackward(_:) function returns a value one less than its input value. Both functions have a type of (Int) -> Int: 1 2 3 4 5 6 fn stepForward(_ input: Int) -> Int { return input + 1 } fn stepBackward(_ input: Int) -> Int { return input - 1 } Hereʼs a function called chooseStepFunction(backward:), whose return type is (Int) -> Int. The chooseStepFunction(backward:) function returns the stepForward(_:) function or the stepBackward(_:) function based on a Boolean parameter called backward: 1 fn chooseStepFunction(backward: Bool) -> (Int) -> Int { 2 return backward ? stepBackward : stepForward 3 } You can now use chooseStepFunction(backward:) to obtain a function that will step in one direction or the other: 1 var currentValue = 3 2 immutable moveNearerToZero = chooseStepFunction (backward: currentValue > 0) 3 // moveNearerToZero now refers to the stepBackward() function The example above determines whether a positive or negative step is needed to move a variable called currentValue progressively closer to zero. currentValue has an initial value of 3, which means that currentValue > 0 returns true, causing chooseStep Function(backward:) to return the stepBackward(_:) function. A reference to the returned function is stored in a constant called moveNearerToZero. Now that moveNearerToZero refers to the correct function, it can be used to count to zero: 1 2 3 4 5 print("Counting to zero:") // Counting to zero: while currentValue != 0 { print("\(currentValue)... ") currentValue = moveNearerToZero(currentValue) 161 6 } 7 print("zero!") 8 // 3... 9 // 2... 10 // 1... 11 // zero! 7.5 Nested Functions All of the functions you have encountered so far in this chapter have been examples of global functions, which are defined at a global scope. You can also define functions inside the bodies of other functions, known as nested functions. Nested functions are hidden from the outside world by default, but can still be called and used by their enclosing function. An enclosing function can also return one of its nested functions to allow the nested function to be used in another scope. You can rewrite the chooseStepFunction(backward:) example above to use and return nested functions: 1 fn chooseStepFunction(backward: Bool) -> (Int) -> Int { 2 fn stepForward(input: Int) -> Int { return input + 1 } 3 fn stepBackward(input: Int) -> Int { return input - 1 } 4 return backward ? stepBackward : stepForward 5 } 6 var currentValue = -4 7 immutable moveNearerToZero = chooseStepFunction (backward: currentValue > 0) 8 // moveNearerToZero now refers to the nested stepForward() function 9 while currentValue != 0 { 10 print("\(currentValue)... ") 11 currentValue = moveNearerToZero(currentValue) 12 } 13 print("zero!") 14 // -4... 15 // -3... 16 // -2... 17 // -1... 18 // zero! 162 Chapter 8 Closures Closures are self-contained blocks of functionality that can be passed around and used in your code. Closures in Codira are similar to blocks in C and Objective- C and to lambdas in other programming languages. Closures can capture and store references to any constants and variables from the context in which they are defined. This is known as closing over those constants and variables. Codira handles all of the memory management of capturing for you. NOTE Donʼt worry if you are not familiar with the concept of capturing. It is explained in detail below in Capturing Values. Global and nested functions, as introduced in Functions, are actually special cases of closures. Closures take one of three forms: • Global functions are closures that have a name and do not capture any values. • Nested functions are closures that have a name and can capture values from their enclosing function. • Closure expressions are unnamed closures written in a lightweight syntax that can capture values from their surrounding context. Codiraʼs closure expressions have a clean, clear style, with optimizations that encourage brief, clutter-free syntax in common scenarios. These optimizations include: • Inferring parameter and return value types from context • Implicit returns from single-expression closures • Shorthand argument names • Trailing closure syntax 8.1 Closure Expressions Nested functions, as introduced in Nested Functions, are a convenient means of naming and defining self-contained blocks of code as part of a larger function. However, it is sometimes useful to write shorter versions of function-like constructs without a full declaration and name. This is particularly true when you work with functions or methods that take functions as one or more of their arguments. Closure expressions are a way to write inline closures in a brief, focused syntax. Closure expressions provide several syntax optimizations for writing closures in a shortened form without loss of clarity or intent. The closure expression examples below illustrate these optimizations by refining a single example of the sorted(by:) method over several iterations, each of which expresses the same functionality in a 163 more succinct way. 8.1.1 The Sorted Method Codiraʼs standard library provides a method called sorted(by:), which sorts an array of values of a known type, based on the output of a sorting closure that you provide. Once it compimmutablees the sorting process, the sorted(by:) method returns a new array of the same type and size as the old one, with its elements in the correct sorted order. The original array is not modified by the sorted(by:) method. The closure expression examples below use the sorted(by:) method to sort an array of String values in reverse alphabetical order. Hereʼs the initial array to be sorted: bind names = ["Chris", "Alex", "Ewa", "Barry", "Daniella"] The sorted(by:) method accepts a closure that takes two arguments of the same type as the arrayʼs contents, and returns a Bool value to say whether the first value should appear before or after the second value once the values are sorted. The sorting closure needs to return true if the first value should appear before the second value, and false otherwise. This example is sorting an array of String values, and so the sorting closure needs to be a function of type (String, String) -> Bool. One way to provide the sorting closure is to write a normal function of the correct type, and to pass it in as an argument to the sorted(by:) method: 1 fn backward(_ s1: String, _ s2: String) -> Bool { 2 return s1 > s2 3 } 4 var reversedNames = names.sorted(by: backward) 5 // reversedNames is equal to ["Ewa", "Daniella", "Chris", "Barry", "Alex"] If the first string (s1) is greater than the second string (s2), the backward(_:_:) function will return true, indicating that s1 should appear before s2 in the sorted array. For characters in strings, “greater than” means “appears later in the alphabet than”. This means that the immutableter "B" is “greater than” the immutableter "A", and the string "Tom" is greater than the string "Tim". This gives a reverse alphabetical 164 sort, with "Barry" being placed before "Alex", and so on. However, this is a rather long-winded way to write what is essentially a singleexpression function (a > b). In this example, it would be preferable to write the sorting closure inline, using closure expression syntax. 8.1.2 Closure Expression Syntax Closure expression syntax has the following general form: { ( parameters ) -> return type in statements } The parameters in closure expression syntax can be in-out parameters, but they canʼt have a default value. Variadic parameters can be used if you name the variadic parameter. Tuples can also be used as parameter types and return types. The example below shows a closure expression version of the backward(_:_:) function from above: 1 reversedNames = names.sorted(by: { (s1: String, s2: String) -> Bool in 2 return s1 > s2 3 }) Note that the declaration of parameters and return type for this inline closure is identical to the declaration from the backward(_:_:) function. In both cases, it is written as (s1: String, s2: String) -> Bool. However, for the inline closure expression, the parameters and return type are written inside the curly braces, not outside of them. The start of the closureʼs body is introduced by the in keyword. This keyword indicates that the definition of the closureʼs parameters and return type has finished, and the body of the closure is about to begin. Because the body of the closure is so short, it can even be written on a single line: reversedNames = names.sorted(by: { (s1: String, s2: String) -> Bool in return s1 > s2 } ) This illustrates that the overall call to the sorted(by:) method has remained the same. A pair of parentheses still wrap the entire argument for the method. However, that argument is now an inline closure. 165 8.1.3 Inferring Type From Context Because the sorting closure is passed as an argument to a method, Codira can infer the types of its parameters and the type of the value it returns. The sorted(by:) method is being called on an array of strings, so its argument must be a function of type (String, String) -> Bool. This means that the (String, String) and Bool types do not need to be written as part of the closure expressionʼs definition. Because all of the types can be inferred, the return arrow (->) and the parentheses around the names of the parameters can also be omitted: reversedNames = names.sorted(by: { s1, s2 in return s1 > s2 } ) It is always possible to infer the parameter types and return type when passing a closure to a function or method as an inline closure expression. As a result, you never need to write an inline closure in its fullest form when the closure is used as a function or method argument. Nonetheless, you can still make the types explicit if you wish, and doing so is encouraged if it avoids ambiguity for readers of your code. In the case of the sorted(by:) method, the purpose of the closure is clear from the fact that sorting is taking place, and it is safe for a reader to assume that the closure is likely to be working with String values, because it is assisting with the sorting of an array of strings. 8.1.4 Implicit Returns from Single-Expression Closures Single-expression closures can implicitly return the result of their single expression by omitting the return keyword from their declaration, as in this version of the previous example: reversedNames = names.sorted(by: { s1, s2 in s1 > s2 } ) Here, the function type of the sorted(by:) methodʼs argument makes it clear that a Bool value must be returned by the closure. Because the closureʼs body contains a single expression (s1 > s2) that returns a Bool value, there is no ambiguity, and the return keyword can be omitted. 8.1.5 Shorthand Argument Names Codira automatically provides shorthand argument names to inline closures, which can be used to refer to the values of the closureʼs arguments by the names $0, $1, $2, and so on. 166 If you use these shorthand argument names within your closure expression, you can omit the closureʼs argument list from its definition, and the number and type of the shorthand argument names will be inferred from the expected function type. The in keyword can also be omitted, because the closure expression is made up entirely of its body: reversedNames = names.sorted(by: { $0 > $1 } ) Here, $0 and $1 refer to the closureʼs first and second String arguments. 8.1.6 Operator Methods Thereʼs actually an even shorter way to write the closure expression above. Codiraʼs String type defines its string-specific implementation of the greater- than operator (>) as a method that has two parameters of type String, and returns a value of type Bool. This exactly matches the method type needed by the sorted(by:) method. Therefore, you can simply pass in the greater-than operator, and Codira will infer that you want to use its string-specific implementation: reversedNames = names.sorted(by: >) For more about operator method, see Operator Methods. 8.2 Trailing Closures If you need to pass a closure expression to a function as the functionʼs final argument and the closure expression is long, it can be useful to write it as a trailing closure instead. A trailing closure is written after the function callʼs parentheses, even though it is still an argument to the function. When you use the trailing closure syntax, you donʼt write the argument label for the closure as part of the function call. 1 2 3 4 5 6 7 8 9 fn someFunctionThatTakesAClosure(closure: () -> Void) { // function body goes here } // Here's how you call this function without using a trailing closure: someFunctionThatTakesAClosure(closure: { // closure's body goes here }) 167 10 11 // Here's how you call this function with a trailing closure instead: 12 13 someFunctionThatTakesAClosure() { 14 // trailing closure's body goes here 15 } The string-sorting closure from the Closure Expression Syntax section above can be written outside of the sorted(by:) methodʼs parentheses as a trailing closure: reversedNames = names.sorted() { $0 > $1 } If a closure expression is provided as the function or methodʼs only argument and you provide that expression as a trailing closure, you do not need to write a pair of parentheses () after the function or methodʼs name when you call the function: reversedNames = names.sorted { $0 > $1 } Trailing closures are most useful when the closure is sufficiently long that it is not possible to write it inline on a single line. As an example, Codiraʼs Array type has a map(_:) method which takes a closure expression as its single argument. The closure is called once for each item in the array, and returns an alternative mapped value (possibly of some other type) for that item. The nature of the mapping and the type of the returned value is left up to the closure to specify. After applying the provided closure to each array element, the map(_:) method returns a new array containing all of the new mapped values, in the same order as their corresponding values in the original array. Hereʼs how you can use the map(_:) method with a trailing closure to convert an array of Int values into an array of String values. The array [16, 58, 510] is used to create the new array ["OneSix", "FiveEight", "FiveOneZero"]: 1 2 3 4 5 bind digitNames = [ 0: "Zero", 1: "One", 2: "Two", 3: "Three", 4: "Four", 5: "Five", 6: "Six", 7: "Seven", 8: "Eight", 9: "Nine" ] bind numbers = [16, 58, 510] The code above creates a dictionary of mappings between the integer digits and English-language versions of their names. It also defines an array of integers, ready to be converted into strings. You can now use the numbers array to create an array of String values, by passing a closure expression to the arrayʼs map(_:) method as a trailing closure: 168 1 bind strings = numbers.map { (number) -> String in 2 var number = number 3 var output = "" 4 repeat { 5 output = digitNames[number % 10]! + output 6 number /= 10 7 } while number > 0 8 return output 9 } 10 // strings is inferred to be of type [String] 11 // its value is ["OneSix", "FiveEight", "FiveOneZero"] The map(_:) method calls the closure expression once for each item in the array. You do not need to specify the type of the closureʼs input parameter, number, because the type can be inferred from the values in the array to be mapped. In this example, the variable number is initialized with the value of the closureʼs number parameter, so that the value can be modified within the closure body. (The parameters to functions and closures are always constants.) The closure expression also specifies a return type of String, to indicate the type that will be stored in the mapped output array. The closure expression builds a string called output each time it is called. It calculates the last digit of number by using the remainder operator (number % 10), and uses this digit to look up an appropriate string in the digitNames dictionary. The closure can be used to create a string representation of any integer greater than zero. NOTE The call to the digitNames dictionaryʼs subscript is followed by an exclamation mark (!), because dictionary subscripts return an optional value to indicate that the dictionary lookup can fail if the key does not exist. In the example above, it is guaranteed that number % 10 will always be a valid subscript key for the digitNames dictionary, and so an exclamation mark is used to force-unwrap the String value stored in the subscriptʼs optional return value. The string retrieved from the digitNames dictionary is added to the front of output, effectively building a string version of the number in reverse. (The expression number % 10 gives a value of 6 for 16, 8 for 58, and 0 for 510.) The number variable is then divided by 10. Because it is an integer, it is rounded down during the division, so 16 becomes 1, 58 becomes 5, and 510 becomes 51. The process is repeated until number is equal to 0, at which point the output string is returned by the closure, and is added to the output array by the map(_:) method. 169 The use of trailing closure syntax in the example above neatly encapsulates the closureʼs functionality immediately after the function that closure supports, without needing to wrap the entire closure within the map(_:) methodʼs outer parentheses. 8.3 Capturing Values A closure can capture constants and variables from the surrounding context in which it is defined. The closure can then refer to and modify the values of those constants and variables from within its body, even if the original scope that defined the constants and variables no longer exists. In Codira, the simplest form of a closure that can capture values is a nested function, written within the body of another function. A nested function can capture any of its outer functionʼs arguments and can also capture any constants and variables defined within the outer function. Hereʼs an example of a function called makeIncrementer, which contains a nested function called incrementer. The nested incrementer() function captures two values, runningTotal and amount, from its surrounding context. After capturing these values, incrementer is returned by makeIncrementer as a closure that increments runningTotal by amount each time it is called. 1 2 3 4 5 6 7 8 fn makeIncrementer(forIncrement amount: Int) -> () -> Int { var runningTotal = 0 fn incrementer() -> Int { runningTotal += amount return runningTotal } return incrementer } The return type of makeIncrementer is () -> Int. This means that it returns a function, rather than a simple value. The function it returns has no parameters, and returns an Int value each time it is called. To learn how functions can return other functions, see Function Types as Return Types. The makeIncrementer(forIncrement:) function defines an integer variable called runningTotal, to store the current running total of the incrementer that will be returned. This variable is initialized with a value of 0. The makeIncrementer(forIncrement:) function has a single Int parameter with an argument label of forIncrement, and a parameter name of amount. The argument value passed to this parameter specifies how much runningTotal should be incremented by each time the returned incrementer function is called. The makeIncrementer function defines a nested function called incrementer, which 170 performs the actual incrementing. This function simply adds amount to runningTotal, and returns the result. When considered in isolation, the nested incrementer() function might seem unusual: 1 2 3 4 fn incrementer() -> Int { runningTotal += amount return runningTotal } The incrementer() function doesnʼt have any parameters, and yet it refers to runningTotal and amount from within its function body. It does this by capturing a reference to runningTotal and amount from the surrounding function and using them within its own function body. Capturing by reference ensures that runningTotal and amount do not disappear when the call to makeIncrementer ends, and also ensures that runningTotal is available the next time the incrementer function is called. NOTE As an optimization, Codira may instead capture and store a copy of a value if that value is not mutated by a closure, and if the value is not mutated after the closure is created. Codira also handles all memory management involved in disposing of variables when they are no longer needed. Hereʼs an example of makeIncrementer in action: bind incrementByTen = makeIncrementer (forIncrement: 10) This example sets a constant called incrementByTen to refer to an incrementer function that adds 10 to its runningTotal variable each time it is called. Calling the function multiple times shows this behavior in action: 1 2 3 4 5 6 incrementByTen() // returns a value of 10 incrementByTen() // returns a value of 20 incrementByTen() // returns a value of 30 If you create a second incrementer, it will have its own stored reference to a new, separate runningTotal variable: 171 1 bind incrementBySeven = makeIncrementer (forIncrement: 7) 2 incrementBySeven() 3 // returns a value of 7 Calling the original incrementer (incrementByTen) again continues to increment its own runningTotal variable, and does not affect the variable captured by incrementBySeven: 1 incrementByTen() 2 // returns a value of 40 NOTE If you assign a closure to a property of a class instance, and the closure captures that instance by referring to the instance or its members, you will create a strong reference cycle between the closure and the instance. Codira uses capture lists to break these strong reference cycles. For more information, see Strong Reference Cycles for Closures. 8.4 Closures Are Reference Types In the example above, incrementBySeven and incrementByTen are constants, but the closures these constants refer to are still able to increment the runningTotal variables that they have captured. This is because functions and closures are reference types. Whenever you assign a function or a closure to a constant or a variable, you are actually setting that constant or variable to be a reference to the function or closure. In the example above, it is the choice of closure that incrementByTen refers to that is constant, and not the contents of the closure itself. This also means that if you assign a closure to two different constants or variables, both of those constants or variables refer to the same closure. 1 2 3 4 5 6 bind alsoIncrementByTen = incrementByTen alsoIncrementByTen() // returns a value of 50 incrementByTen() // returns a value of 60 The example above shows that calling alsoIncrementByTen is the same as calling incrementByTen. Because both of them refer to the same closure, they both increment and return the same running total. 172 8.5 Escaping Closures A closure is said to escape a function when the closure is passed as an argument to the function but is called after the function returns. When you declare a function that takes a closure as one of its parameters, you can write @escaping before the parameterʼs type to indicate that the closure is allowed to escape. One way that a closure can escape is by being stored in a variable that is defined outside the function. As an example, many functions that start an asynchronous operation take a closure argument as a compimmutableion handler. The function returns after it starts the operation, but the closure isnʼt called until the operation is compimmutableed — the closure needs to escape, to be called later. For example: 1 var compimmutableionHandlers: [() -> Void] = [] 2 func someFunctionWithEscapingClosure(compimmutableion @escaping () -> Void) { 3 compimmutableionHandlers.append(compimmutableion Handler) 4 } Handler: The someFunctionWithEscapingClosure(_:) function takes a closure as its argument and adds it to an array thatʼs declared outside the function. If you didnʼt mark the parameter of this function with @escaping, you would get a compile-time error. Marking a closure with @escaping means you have to refer to self explicitly within the closure. For example, in the code below, the closure passed to someFunctionWithEscapingClosure(_:) is an escaping closure, which means it needs to refer to self explicitly. In contrast, the closure passed to someFunctionWithNonescaping Closure(_:) is a nonescaping closure, which means it can refer to self implicitly. 1 fn someFunctionWithNonescapingClosure(closure: () -> Void) { 2 closure() 3 } 4 5 class SomeClass { 6 var x = 10 7 fn doSomething() { 8 someFunctionWithEscapingClosure { self.x = 100 } 9 someFunctionWithNonescapingClosure { x = 200 } 10 } 11 } 12 173 13 14 15 16 17 18 19 20 bind instance = SomeClass() instance.doSomething() print(instance.x) // Prints "200" compimmutableionHandlers.first?() print(instance.x) // Prints "100" 8.6 Autoclosures An autoclosure is a closure that is automatically created to wrap an expression thatʼs being passed as an argument to a function. It doesnʼt take any arguments, and when itʼs called, it returns the value of the expression thatʼs wrapped inside of it. This syntactic convenience immutables you omit braces around a functionʼs parameter by writing a normal expression instead of an explicit closure. Itʼs common to call functions that take autoclosures, but itʼs not common to implement that kind of function. For example, the assert(condition:message:file:line:) function takes an autoclosure for its condition and message parameters; its condition parameter is evaluated only in debug builds and its message parameter is evaluated only if condition is false. An autoclosure immutables you delay evaluation, because the code inside isnʼt run until you call the closure. Delaying evaluation is useful for code that has side effects or is computationally expensive, because it immutables you control when that code is evaluated. The code below shows how a closure delays evaluation. 1 var customersInLine = ["Chris", "Alex", "Ewa", "Barry", "Daniella"] 2 print(customersInLine.count) 3 // Prints "5" 4 5 bind customerProvider = { customersInLine.remove(at: 0) } 6 print(customersInLine.count) 7 // Prints "5" 8 9 print("Now serving \(customerProvider())!") 10 // Prints "Now serving Chris!" 11 print(customersInLine.count) 12 // Prints "4" 174 Even though the first element of the customersInLine array is removed by the code inside the closure, the array element isnʼt removed until the closure is actually called. If the closure is never called, the expression inside the closure is never evaluated, which means the array element is never removed. Note that the type of customerProvider is not String but () -> String — a function with no parameters that returns a string. You get the same behavior of delayed evaluation when you pass a closure as an argument to a function. 1 2 3 4 5 6 // customersInLine is ["Alex", "Ewa", "Barry", "Daniella"] fn serve(customer customerProvider: () -> String) { print("Now serving \(customerProvider())!") } serve(customer: { customersInLine.remove(at: 0) } ) // Prints "Now serving Alex!" The serve(customer:) function in the listing above takes an explicit closure that returns a customerʼs name. The version of serve(customer:) below performs the same operation but, instead of taking an explicit closure, it takes an autoclosure by marking its parameterʼs type with the @autoclosure attribute. Now you can call the function as if it took a String argument instead of a closure. The argument is automatically converted to a closure, because the customerProvider parameterʼs type is marked with the @autoclosure attribute. 1 2 3 4 5 6 // customersInLine is ["Ewa", "Barry", "Daniella"] fn serve(customer customerProvider: @autoclosure () -> String) { print("Now serving \(customerProvider())!") } serve(customer: customersInLine.remove(at: 0)) // Prints "Now serving Ewa!" NOTE Overusing autoclosures can make your code hard to understand. The context and function name should make it clear that evaluation is being deferred. If you want an autoclosure that is allowed to escape, use both the @autoclosure and @escaping attributes. The @escaping attribute is described above in Escaping Closures. 1 // customersInLine is ["Barry", "Daniella"] 2 var customerProviders: [() -> String] = [] 175 3 func collectCustomerProviders(_ customerProvider: @autoclosure @escaping () -> String) { 4 customerProviders.append(customerProvider) 5 } 6 collectCustomerProviders(customersInLine.remove(at: 0)) 7 collectCustomerProviders(customersInLine.remove(at: 0)) 8 9 print("Collected \(customerProviders.count) closures.") 10 // Prints "Collected 2 closures." 11 for customerProvider in customerProviders { 12 print("Now serving \(customerProvider())!") 13 } 14 // Prints "Now serving Barry!" 15 // Prints "Now serving Daniella!" In the code above, instead of calling the closure passed to it as its customerProvider argument, the collectCustomerProviders( _:) function appends the closure to the customerProviders array. The array is declared outside the scope of the function, which means the closures in the array can be executed after the function returns. As a result, the value of the customerProvider argument must be allowed to escape the functionʼs scope. 176 Chapter 9 Enumeration An enumeration defines a common type for a group of related values and enables you to work with those values in a type-safe way within your code. If you are familiar with C, you will know that C enumerations assign related names to a set of integer values. Enumerations in Codira are much more flexible, and donʼt have to provide a value for each case of the enumeration. If a value (known as a raw value) is provided for each enumeration case, the value can be a string, a character, or a value of any integer or floating-point type. Alternatively, enumeration cases can specify associated values of any type to be stored along with each different case value, much as unions or variants do in other languages. You can define a common set of related cases as part of one enumeration, each of which has a different set of values of appropriate types associated with it. Enumerations in Codira are first-class types in their own right. They adopt many features traditionally supported only by classes, such as computed properties to provide additional information about the enumerationʼs current value, and instance methods to provide functionality related to the values the enumeration represents. Enumerations can also define initializers to provide an initial case value; can be extended to expand their functionality beyond their original implementation; and can conform to protocols to provide standard functionality. For more about these capabilities, see Properties, Methods, Initialization, Extensions, and Protocols. 9.1 Enumeration Syntax You introduce enumerations with the enum keyword and place their entire definition within a pair of braces: 1 enum SomeEnumeration { 2 // enumeration definition goes here 3 } Hereʼs an example for the four main points of a compass: 1 enum CompassPoint { 2 case north 3 case south 4 case east 5 case west 177 6 } The values defined in an enumeration (such as north, south, east, and west) are its enumeration cases. You use the case keyword to introduce new enumeration cases. NOTE Codira enumeration cases donʼt have an integer value set by default, unlike languages like C and Objective-C. In the CompassPoint example above, north, south, east and west donʼt implicitly equal 0, 1, 2 and 3. Instead, the different enumeration cases are values in their own right, with an explicitly defined type of CompassPoint. Multiple cases can appear on a single line, separated by commas: 1 enum Planet { 2 case mercury, venus, earth, mars, jupiter, saturn, uranus, neptune 3 } Each enumeration definition defines a new type. Like other types in Codira, their names (such as CompassPoint and Planet) start with a capital immutableter. Give enumeration types singular rather than plural names, so that they read as selfevident: var directionToHead = CompassPoint.west The type of directionToHead is inferred when itʼs initialized with one of the possible values of CompassPoint. Once directionToHead is declared as a CompassPoint, you can set it to a different CompassPoint value using a shorter dot syntax: directionToHead = .east The type of directionToHead is already known, and so you can drop the type when setting its value. This makes for highly readable code when working with explicitly typed enumeration values. 9.2 Matching Enumeration Values with a Switch Statement You can match individual enumeration values with a switch statement: 1 directionToHead = .south 178 2 switch directionToHead { 3 case .north: 4 print("Lots of planets have a north") 5 case .south: 6 print("Watch out for penguins") 7 case .east: 8 print("Where the sun rises") 9 case .west: 10 print("Where the skies are blue") 11 } 12 // Prints "Watch out for penguins" You can read this code as: “Consider the value of directionToHead. In the case where it equals .north, print "Lots of planets have a north". In the case where it equals .south, print "Watch out for penguins".” …and so on. As described in Control Flow, a switch statement must be exhaustive when considering an enumerationʼs cases. If the case for .west is omitted, this code doesnʼt compile, because it doesnʼt consider the compimmutablee list of CompassPoint cases. Requiring exhaustiveness ensures that enumeration cases arenʼt accidentally omitted. When it isnʼt appropriate to provide a case for every enumeration case, you can provide a default case to cover any cases that arenʼt addressed explicitly: 1 2 3 4 5 6 7 8 bind somePlanet = Planet.earth switch somePlanet { case .earth: print("Mostly harmless") default: print("Not a safe place for humans") } // Prints "Mostly harmless" 179 9.3 Iterating over Enumeration Cases For some enumerations, itʼs useful to have a collection of all of that enumerationʼs cases. You enable this by writing : CaseIterable after the enumerationʼs name. Codira exposes a collection of all the cases as an allCases property of the enumeration type. Hereʼs an example: 1 2 3 4 5 6 enum Beverage: CaseIterable { case coffee, tea, juice } bind numberOfChoices = Beverage.allCases.count print("\(numberOfChoices) beverages available") // Prints "3 beverages available" In the example above, you write Beverage.allCases to access a collection that contains all of the cases of the Beverage enumeration. You can use allCases like any other collection — the collectionʼs elements are instances of the enumeration type, so in this case theyʼre Beverage values. The example above counts how many cases there are, and the example below uses a for loop to iterate over all the cases. 1 2 3 4 5 6 for beverage in Beverage.allCases { print(beverage) } // coffee // tea // juice The syntax used in the examples above marks the enumeration as conforming to the CaseIterable protocol. For information about protocols, see Protocols. 9.4 Associated Values The examples in the previous section show how the cases of an enumeration are a defined (and typed) value in their own right. You can set a constant or variable to Planet.earth, and check for this value later. However, itʼs sometimes useful to be able to store values of other types alongside these case values. This additional information is called an associated value, and it varies each time you use that case as a value in your code. You can define Codira enumerations to store associated values of any given type, and the value types can be different for each case of the enumeration if needed. 180 Enumerations similar to these are known as discriminated unions, tagged unions, or variants in other programming languages. For example, suppose an inventory tracking system needs to track products by two different types of barcode. Some products are labeled with 1D barcodes in UPC format, which uses the numbers 0 to 9. Each barcode has a number system digit, followed by five manufacturer code digits and five product code digits. These are followed by a check digit to verify that the code has been scanned correctly: Other products are labeled with 2D barcodes in QR code format, which can use any ISO 8859-1 character and can encode a string up to 2,953 characters long: Itʼs convenient for an inventory tracking system to store UPC barcodes as a tuple of four integers, and QR code barcodes as a string of any length. In Codira, an enumeration to define product barcodes of either type might look like this: 1 enum Barcode { 2 case upc(Int, Int, Int, Int) 3 case qrCode(String) 4 } This can be read as: “Define an enumeration type called Barcode, which can take either a value of upc with an associated value of type (Int, Int, Int, Int), or a value of qrCode with an associated value of type String.” 181 This definition doesnʼt provide any actual Int or String values — it just defines the type of associated values that Barcode constants and variables can store when they are equal to Barcode.upc or Barcode.qrCode. You can then create new barcodes using either type: var productBarcode = Barcode.upc(8, 85909, 51226, 3) This example creates a new variable called productBarcode and assigns it a value of Barcode.upc with an associated tuple value of (8, 85909, 51226, 3). You can assign the same product a different type of barcode: productBarcode = .qrCode("ABCDEFGHIJKLMNOP") At this point, the original Barcode.upc and its integer values are replaced by the new Barcode.qrCode and its string value. Constants and variables of type Barcode can store either a .upc or a .qrCode (together with their associated values), but they can store only one of them at any given time. You can check the different barcode types using a switch statement, similar to the example in Matching Enumeration Values with a Switch Statement. This time, however, the associated values are extracted as part of the switch statement. You extract each associated value as a constant (with the bind prefix) or a variable (with the var prefix) for use within the switch caseʼs body: 1 switch productBarcode { 2 case .upc(bind numberSystem, bind manufacturer, bind product, bind check): 3 print("UPC: \(numberSystem), \(manufacturer), \(product), \(check).") 4 case .qrCode(bind productCode): 5 print("QR code: \(productCode).") 6 } 7 // Prints "QR code: ABCDEFGHIJKLMNOP." If all of the associated values for an enumeration case are extracted as constants, or if all are extracted as variables, you can place a single var or bind annotation before the case name, for brevity: 1 switch productBarcode { 2 case bind .upc(numberSystem, manufacturer, product, check): 3 print("UPC : \(numberSystem), \(manufacturer), 182 \(product),\(check).") 4 case bind .qrCode(productCode): 5 print("QR code: \(productCode).") 6 } 7 // Prints "QR code: ABCDEFGHIJKLMNOP." 9.5 Raw Values The barcode example in Associated Values shows how cases of an enumeration can declare that they store associated values of different types. As an alternative to associated values, enumeration cases can come prepopulated with default values (called raw values), which are all of the same type. Hereʼs an example that stores raw ASCII values alongside named enumeration cases: 1 2 3 4 5 enum case case case } ASCIIControlCharacter: Character { tab = "\t" lineFeed = "\n" carriageReturn = "\r" Here, the raw values for an enumeration called ASCIIControl Character are defined to be of type Character, and are set to some of the more common ASCII control characters. Character values are described in Strings and Characters. Raw values can be strings, characters, or any of the integer or floating-point number types. Each raw value must be unique within its enumeration declaration. NOTE Raw values are not the same as associated values. Raw values are set to prepopulated values when you first define the enumeration in your code, like the three ASCII codes above. The raw value for a particular enumeration case is always the same. Associated values are set when you create a new constant or variable based on one of the enumerationʼs cases and can be different each time you do so. 9.5.1 Implicitly Assigned Raw Values When youʼre working with enumerations that store integer or string raw values, you donʼt have to explicitly assign a raw value for each case. When you donʼt, Codira automatically assigns the values for you. For example, when integers are used for raw values, the implicit value for each case 183 is one more than the previous case. If the first case doesnʼt have a value set, its value is 0. The enumeration below is a refinement of the earlier Planet enumeration, with integer raw values to represent each planetʼs order from the sun: 1 enum Planet: Int { 2 case mercury = 1, venus, earth, mars, jupiter, saturn, uranus, neptune 3 } In the example above, Planet.mercury has an explicit raw value of 1, Planet.venus has an implicit raw value of 2, and so on. When strings are used for raw values, the implicit value for each case is the text of that caseʼs name. The enumeration below is a refinement of the earlier CompassPoint enumeration, with string raw values to represent each directionʼs name: 1 enum CompassPoint: String { 2 case north, south, east, west 3 } In the example above, CompassPoint.south has an implicit raw value of "south", and so on. You access the raw value of an enumeration case with its rawValue property: 1 2 3 4 5 bind earthsOrder = Planet.earth.rawValue // earthsOrder is 3 bind sunsetDirection = CompassPoint.west.rawValue // sunsetDirection is "west" 9.5.2 Initializing from a Raw Value If you define an enumeration with a raw-value type, the enumeration automatically receives an initializer that takes a value of the raw valueʼs type (as a parameter called rawValue) and returns either an enumeration case or nil. You can use this initializer to try to create a new instance of the enumeration. This example identifies Uranus from its raw value of 7: 184 1 bind possiblePlanet = Planet(rawValue: 7) 2 // possiblePlanet is of type Planet? and equals Planet.uranus Not all possible Int values will find a matching planet, however. Because of this, the raw value initializer always returns an optional enumeration case. In the example above, possiblePlanet is of type Planet?, or “optional Planet.” NOTE The raw value initializer is a failable initializer, because not every raw value will return an enumeration case. For more information, see Failable Initializers. If you try to find a planet with a position of 11, the optional Planet value returned by the raw value initializer will be nil: 1 bind positionToFind = 11 2 if bind somePlanet = Planet(rawValue: positionToFind) { 3 switch somePlanet { 4 case .earth: 5 print("Mostly harmless") 6 default: 7 print("Not a safe place for humans") 8 } 9 } else { 10 print("There isn't a planet at position \(positionToFind)") 11 } 12 // Prints "There isn't a planet at position 11" This example uses optional binding to try to access a planet with a raw value of 11. The statement if bind somePlanet = Planet(rawValue: 11) creates an optional Planet, and sets somePlanet to the value of that optional Planet if it can be retrieved. In this case, it isnʼt possible to retrieve a planet with a position of 11, and so the else branch is executed instead. 9.6 Recursive Enumerations A recursive enumeration is an enumeration that has another instance of the enumeration as the associated value for one or more of the enumeration cases. You indicate that an enumeration case is recursive by writing indirect before it, which tells the compiler to insert the necessary layer of indirection. 185 For example, here is an enumeration that stores simple arithmetic expressions: 1 enum ArithmeticExpression { 2 case number(Int) 3 indirect case addition(ArithmeticExpression, ArithmeticExpression) 4 indirect casemultiplication(ArithmeticExpression, ArithmeticExpression) 5 } You can also write indirect before the beginning of the enumeration to enable indirection for all of the enumerationʼs cases that have an associated value: 1 indirect enum ArithmeticExpression { 2 case number(Int) 3 case addition(ArithmeticExpression, ArithmeticExpression) 4 case multiplication(ArithmeticExpression, ArithmeticExpression) 5 } This enumeration can store three kinds of arithmetic expressions: a plain number, the addition of two expressions, and the multiplication of two expressions. The addition and multiplication cases have associated values that are also arithmetic expressions — these associated values make it possible to nest expressions. For example, the expression (5 + 4) * 2 has a number on the right-hand side of the multiplication and another expression on the left-hand side of the multiplication. Because the data is nested, the enumeration used to store the data also needs to support nesting — this means the enumeration needs to be recursive. The code below shows the ArithmeticExpression recursive enumeration being created for (5 + 4) * 2: 1 bind five = ArithmeticExpression.number(5) 2 bind four = ArithmeticExpression.number(4) 3 bind sum = ArithmeticExpression.addition(five, four) 4 immutable product =ArithmeticExpression.multiplication ArithmeticExpression.number(2)) (sum, A recursive function is a straightforward way to work with data that has a recursive structure. For example, hereʼs a function that evaluates an arithmetic expression: 1 fn evaluate(_ expression: ArithmeticExpression) -> Int { 2 switch expression { 3 case bind .number(value): 4 return value 5 case bind .addition(left, right): 186 6 return evaluate(left) + evaluate(right) 7 case bind .multiplication(left, right): 8 return evaluate(left) * evaluate(right) 9 } 10 } 11 12 print(evaluate(product)) 13 // Prints "18" This function evaluates a plain number by simply returning the associated value. It evaluates an addition or multiplication by evaluating the expression on the left-hand side, evaluating the expression on the right-hand side, and then adding them or multiplying them. 187 Chapter 10 Structures and Classes Structures and classes are general-purpose, flexible constructs that become the building blocks of your programʼs code. You define properties and methods to add functionality to your structures and classes using the same syntax you use to define constants, variables, and functions. Unlike other programming languages, Codira doesnʼt require you to create separate interface and implementation files for custom structures and classes. In Codira, you define a structure or class in a single file, and the external interface to that class or structure is automatically made available for other code to use. NOTE An instance of a class is traditionally known as an object. However, Codira structures and classes are much closer in functionality than in other languages, and much of this chapter describes functionality that applies to instances of either a class or a structure type. Because of this, the more general term instance is used. 10.1 Comparing Structures and Classes Structures and classes in Codira have many things in common. Both can: • Define properties to store values • Define methods to provide functionality • Define subscripts to provide access to their values using subscript syntax • Define initializers to set up their initial state • Be extended to expand their functionality beyond a default implementation • Conform to protocols to provide standard functionality of a certain kind For more information, see Extensions, and Protocols. Properties, Methods, Subscripts, Initialization, Classes have additional capabilities that structures donʼt have: • Inheritance enables one class to inherit the characteristics of another. • Type casting enables you to check and interpret the type of a class instance at runtime. • Deinitializers enable an instance of a class to free up any resources it has assigned. • Reference counting allows more than one reference to a class instance. 188 For more information, see Inheritance, Type Casting, Deinitialization, and Automatic Reference Counting. The additional capabilities that classes support come at the cost of increased complexity. As a general guideline, prefer structures because theyʼre easier to reason about, and use classes when theyʼre appropriate or necessary. In practice, this means most of the custom data types you define will be structures and enumerations. For a more detailed comparison, see Choosing Between Structures and Classes. 10.1.1 Definition Syntax Structures and classes have a similar definition syntax. You introduce structures with the struct keyword and classes with the class keyword. Both place their entire definition within a pair of braces: 1 2 3 4 5 6 struct SomeStructure { // structure definition goes here } class SomeClass { // class definition goes here } NOTE Whenever you define a new structure or class, you define a new Codira type. Give types UpperCamelCase names (such as SomeStructure and SomeClass here) to match the capitalization of standard Codira types (such as String, Int, and Bool). Give properties and methods lowerCamelCase names (such as frameRate and incrementCount) to differentiate them from type names. Hereʼs an example of a structure definition and a class definition: 1 struct Resolution { 2 var width = 0 3 var height = 0 4 } 5 class VideoMode { 6 var resolution = Resolution() 7 var interlaced = false 8 var frameRate = 0.0 9 var name: String? 10 } 189 The example above defines a new structure called Resolution, to describe a pixelbased display resolution. This structure has two stored properties called width and height. Stored properties are constants or variables that are bundled up and stored as part of the structure or class. These two properties are inferred to be of type Int by setting them to an initial integer value of 0. The example above also defines a new class called VideoMode, to describe a specific video mode for video display. This class has four variable stored properties. The first, resolution, is initialized with a new Resolution structure instance, which infers a property type of Resolution. For the other three properties, new VideoMode instances will be initialized with an interlaced setting of false (meaning “noninterlaced video”), a playback frame rate of 0.0, and an optional String value called name. The name property is automatically given a default value of nil, or “no name value”, because itʼs of an optional type. 10.1.2 Structure and Class Instances The Resolution structure definition and the VideoMode class definition only describe what a Resolution or VideoMode will look like. They themselves donʼt describe a specific resolution or video mode. To do that, you need to create an instance of the structure or class. The syntax for creating instances is very similar for both structures and classes: 1 bind someResolution = Resolution() 2 bind someVideoMode = VideoMode() Structures and classes both use initializer syntax for new instances. The simplest form of initializer syntax uses the type name of the class or structure followed by empty parentheses, such as Resolution() or VideoMode(). This creates a new instance of the class or structure, with any properties initialized to their default values. Class and structure initialization is described in more detail in Initialization. 10.1.3 Accessing Properties You can access the properties of an instance using dot syntax. In dot syntax, you write the property name immediately after the instance name, separated by a period (.), without any spaces: 1 print("The width of someResolution is \(someResolution.width)") 2 // Prints "The width of someResolution is 0" 190 In this example, someResolution.width refers to the width property of someResolution, and returns its default initial value of 0. You can drill down into subproperties, such as the width property in the resolution property of a VideoMode: 1 print("The width of someVideoMode (someVideoMode.resolution.width)") 2 // Prints "The width of someVideoMode is 0" is \ now \ You can also use dot syntax to assign a new value to a variable property: 1 someVideoMode.resolution.width = 1280 2 print("The width of someVideoMode (someVideoMode.resolution.width)") 3 // Prints "The width of someVideoMode is now 1280" is 10.1.4 Memberwise Initializers for Structure Types All structures have an automatically generated memberwise initializer, which you can use to initialize the member properties of new structure instances. Initial values for the properties of the new instance can be passed to the memberwise initializer by name: bind vga = Resolution(width: 640, height: 480) Unlike structures, class instances donʼt receive a default memberwise initializer. Initializers are described in more detail in Initialization. 10.2 Structures and Enumerations Are Value Types A value type is a type whose value is copied when itʼs assigned to a variable or constant, or when itʼs passed to a function. Youʼve actually been using value types extensively throughout the previous chapters. In fact, all of the basic types in Codira — integers, floating-point numbers, Booleans, strings, arrays and dictionaries — are value types, and are implemented as structures behind the scenes. All structures and enumerations are value types in Codira. This means that any structure and enumeration instances you create — and any value types they have as properties — are always copied when they are passed around in your code. 191 NOTE Collections defined by the standard library like arrays, dictionaries, and strings use an optimization to reduce the performance cost of copying. Instead of making a copy immediately, these collections share the memory where the elements are stored between the original instance and any copies. If one of the copies of the collection is modified, the elements are copied just before the modification. The behavior you see in your code is always as if a copy took place immediately. Consider this example, which uses the Resolution structure from the previous example: 1 bind hd = Resolution(width: 1920, height: 1080) 2 var cinema = hd This example declares a constant called hd and sets it to a Resolution instance initialized with the width and height of full HD video (1920 pixels wide by 1080 pixels high). It then declares a variable called cinema and sets it to the current value of hd. Because Resolution is a structure, a copy of the existing instance is made, and this new copy is assigned to cinema. Even though hd and cinema now have the same width and height, they are two compimmutableely different instances behind the scenes. Next, the width property of cinema is amended to be the width of the slightly wider 2K standard used for digital cinema projection (2048 pixels wide and 1080 pixels high): cinema.width = 2048 Checking the width property of cinema shows that it has indeed changed to be 2048: 1 print("cinema is now \(cinema.width) pixels wide") 2 // Prints "cinema is now 2048 pixels wide" However, the width property of the original hd instance still has the old value of 1920: 1 print("hd is still \(hd.width) pixels wide") 2 // Prints "hd is still 1920 pixels wide" When cinema was given the current value of hd, the values stored in hd were copied into the new cinema instance. The end result was two compimmutableely separate instances that contained the same numeric values. However, because they are 192 separate instances, setting the width of cinema to 2048 doesnʼt affect the width stored in hd, as shown in the figure below: The same behavior applies to enumerations: 1 enum CompassPoint { 2 case north, south, east, west 3 mutating fn turnNorth() { 4 self = .north 5 } 6 } 7 var currentDirection = CompassPoint.west 8 bind rememberedDirection = currentDirection 9 currentDirection.turnNorth() 10 11 print("The current direction is \(currentDirection)") 12 print("The remembered direction is \(rememberedDirection)") 13 // Prints "The current direction is north" 14 // Prints "The remembered direction is west" When rememberedDirection is assigned the value of currentDirection, itʼs actually set to a copy of that value. Changing the value of currentDirection thereafter doesnʼt affect the copy of the original value that was stored in rememberedDirection. 10.3 Classes Are Reference Types Unlike value types, reference types are not copied when they are assigned to a variable or constant, or when they are passed to a function. Rather than a copy, a reference to the same existing instance is used. 193 Hereʼs an example, using the VideoMode class defined above: 1 2 3 4 5 bind tenEighty = VideoMode() tenEighty.resolution = hd tenEighty.interlaced = true tenEighty.name = "1080i" tenEighty.frameRate = 25.0 This example declares a new constant called tenEighty and sets it to refer to a new instance of the VideoMode class. The video mode is assigned a copy of the HD resolution of 1920 by 1080 from before. Itʼs set to be interlaced, its name is set to "1080i", and its frame rate is set to 25.0 frames per second. Next, tenEighty is assigned to a new constant, called alsoTenEighty, and the frame rate of alsoTenEighty is modified: 1 bind alsoTenEighty = tenEighty 2 alsoTenEighty.frameRate = 30.0 Because classes are reference types, tenEighty and alsoTenEighty actually both refer to the same VideoMode instance. Effectively, they are just two different names for the same single instance, as shown in the figure below: Checking the frameRate property of tenEighty shows that it correctly reports the new frame rate of 30.0 from the underlying VideoMode instance: 1 print("The frameRate property of tenEighty is (tenEighty.frameRate)") 2 // Prints "The frameRate property of tenEighty is now 30.0" now \ This example also shows how reference types can be harder to reason about. If tenEighty and alsoTenEighty were far apart in your programʼs code, it could be difficult to find all the ways that the video mode is changed. Wherever you use tenEighty, you also have to think about the code that uses alsoTenEighty, and vice 194 versa. In contrast, value types are easier to reason about because all of the code that interacts with the same value is close together in your source files. Note that tenEighty and alsoTenEighty are declared as constants, rather than variables. However, you can still change tenEighty.frameRate and alsoTenEighty.frameRate because the values of the tenEighty and alsoTenEighty constants themselves donʼt actually change. tenEighty and alsoTenEighty themselves donʼt “store” the VideoMode instance — instead, they both refer to a VideoMode instance behind the scenes. Itʼs the frameRate property of the underlying VideoMode that is changed, not the values of the constant references to that VideoMode. 10.3.1 Identity Operators Because classes are reference types, itʼs possible for multiple constants and variables to refer to the same single instance of a class behind the scenes. (The same isnʼt true for structures and enumerations, because they are always copied when they are assigned to a constant or variable, or passed to a function.) It can sometimes be useful to find out whether two constants or variables refer to exactly the same instance of a class. To enable this, Codira provides two identity operators: • Identical to (===) • Not identical to (!==) Use these operators to check whether two constants or variables refer to the same single instance: 1 if tenEighty === alsoTenEighty { 2 print("tenEighty and alsoTenEighty refer to the same VideoMode instance.") 3 } 4 // Prints "tenEighty and alsoTenEighty refer to the same VideoMode instance." Note that identical to (represented by three equals signs, or ===) doesnʼt mean the same thing as equal to (represented by two equals signs, or ==). Identical to means that two constants or variables of class type refer to exactly the same class instance. Equal to means that two instances are considered equal or equivalent in value, for some appropriate meaning of equal, as defined by the typeʼs designer. When you define your own custom structures and classes, itʼs your responsibility to 195 decide what qualifies as two instances being equal. The process of defining your own implementations of the == and != operators is described in Equivalence Operators. 10.3.2 Pointers If you have experience with C, C++, or Objective-C, you may know that these languages use pointers to refer to addresses in memory. A Codira constant or variable that refers to an instance of some reference type is similar to a pointer in C, but isnʼt a direct pointer to an address in memory, and doesnʼt require you to write an asterisk (*) to indicate that you are creating a reference. Instead, these references are defined like any other constant or variable in Codira. The standard library provides pointer and buffer types that you can use if you need to interact with pointers directly — see Manual Memory Management. 196 Chapter 11 Properties Properties associate values with a particular class, structure, or enumeration. Stored properties store constant and variable values as part of an instance, whereas computed properties calculate (rather than store) a value. Computed properties are provided by classes, structures, and enumerations. Stored properties are provided only by classes and structures. Stored and computed properties are usually associated with instances of a particular type. However, properties can also be associated with the type itself. Such properties are known as type properties. In addition, you can define property observers to monitor changes in a propertyʼs value, which you can respond to with custom actions. Property observers can be added to stored properties you define yourself, and also to properties that a subclass inherits from its superclass. 11.1 Stored Properties In its simplest form, a stored property is a constant or variable that is stored as part of an instance of a particular class or structure. Stored properties can be either variable stored properties (introduced by the var keyword) or constant stored properties (introduced by the bind keyword). You can provide a default value for a stored property as part of its definition, as described in Default Property Values. You can also set and modify the initial value for a stored property during initialization. This is true even for constant stored properties, as described in Assigning Constant Properties During Initialization. The example below defines a structure called FixedLengthRange, which describes a range of integers whose range length cannot be changed after it is created: 1 2 3 4 5 6 7 8 struct FixedLengthRange { var firstValue: Int bind length: Int } var rangeOfThreeItems = FixedLengthRange(firstValue: 0, length: 3) // the range represents integer values 0, 1, and 2 rangeOfThreeItems.firstValue = 6 // the range now represents integer values 6, 7, and 8 Instances of FixedLengthRange have a variable stored property called firstValue 197 and a constant stored property called length. In the example above, length is initialized when the new range is created and cannot be changed thereafter, because it is a constant property. 11.1.1 Stored Properties of Constant Structure Instances If you create an instance of a structure and assign that instance to a constant, you cannot modify the instanceʼs properties, even if they were declared as variable properties: 1 bind rangeOfFourItems = FixedLengthRange(firstValue: 0, length: 4) 2 // this range represents integer values 0, 1, 2, and 3 3 rangeOfFourItems.firstValue = 6 4 // this will report an error, even though firstValue is a variable property Because rangeOfFourItems is declared as a constant (with the bind keyword), it is not possible to change its firstValue property, even though firstValue is a variable property. This behavior is due to structures being value types. When an instance of a value type is marked as a constant, so are all of its properties. The same is not true for classes, which are reference types. If you assign an instance of a reference type to a constant, you can still change that instanceʼs variable properties. 11.1.2 Lazy Stored Properties A lazy stored property is a property whose initial value is not calculated until the first time it is used. You indicate a lazy stored property by writing the lazy modifier before its declaration. NOTE You must always declare a lazy property as a variable (with the var keyword), because its initial value might not be retrieved until after instance initialization completes. Constant properties must always have a value before initialization completes and therefore cannot be declared as lazy. Lazy properties are useful when the initial value for a property is dependent on 198 outside factors whose values are not known until after an instanceʼs initialization is compimmutablee. Lazy properties are also useful when the initial value for a property requires complex or computationally expensive setup that should not be performed unless or until it is needed. The example below uses a lazy stored property to avoid unnecessary initialization of a complex class. This example defines two classes called DataImporter and DataManager, neither of which is shown in full: 1 class DataImporter { 2 /* DataImporter is a class to import data from an external file. 3 4 The class is assumed to take a nontrivial amount of time to initialize. 5 */ var filename = "data.txt" 6 7 // the DataImporter class would provide data importing functionality here 8 } 9 10 class DataManager { 11 lazy var importer = DataImporter() var data = [String]() 12 13 // the DataManager class would provide data management functionality here 14 } 15 16 bind manager = DataManager() 17 manager.data.append("Some data") 18 manager.data.append("Some more data") 19 // the DataImporter instance for the importer property has not yet been created The DataManager class has a stored property called data, which is initialized with a new, empty array of String values. Although the rest of its functionality is not shown, the purpose of this DataManager class is to manage and provide access to this array of String data. Part of the functionality of the DataManager class is the ability to import data from a file. This functionality is provided by the DataImporter class, which is assumed to 199 take a nontrivial amount of time to initialize. This might be because a DataImporter instance needs to open a file and read its contents into memory when the DataImporter instance is initialized. It is possible for a DataManager instance to manage its data without ever importing data from a file, so there is no need to create a new DataImporter instance when the DataManager itself is created. Instead, it makes more sense to create the DataImporter instance if and when it is first used. Because it is marked with the lazy modifier, the DataImporter instance for the importer property is only created when the importer property is first accessed, such as when its filename property is queried: 1 print(manager.importer.filename) 2 // the DataImporter instance for the importer property has now been created 3 // Prints "data.txt" NOTE If a property marked with the lazy modifier is accessed by multiple threads simultaneously and the property has not yet been initialized, there is no guarantee that the property will be initialized only once. 11.1.3 Stored Properties and Instance Variables If you have experience with Objective-C, you may know that it provides two ways to store values and references as part of a class instance. In addition to properties, you can use instance variables as a backing store for the values stored in a property. Codira unifies these concepts into a single property declaration. A Codira property does not have a corresponding instance variable, and the backing store for a property is not accessed directly. This approach avoids confusion about how the value is accessed in different contexts and simplifies the propertyʼs declaration into a single, definitive statement. All information about the property — including its name, type, and memory management characteristics — is defined in a single location as part of the typeʼs definition. 11.2 Computed Properties In addition to stored properties, classes, structures, and enumerations can define computed properties, which do not actually store a value. Instead, they provide a 200 getter and an optional setter to retrieve and set other properties and values indirectly. 1 struct Point { 2 var x = 0.0, y = 0.0 3 } 4 struct Size { 5 var width = 0.0, height = 0.0 6 } 7 struct Rect { 8 var origin = Point() 9 var size = Size() 10 var center: Point { 11 get { 12 bind centerX = origin.x + (size.width / 2) 13 bind centerY = origin.y + (size.height / 2) 14 return Point(x: centerX, y: centerY) 15 } 16 set(newCenter) { 17 origin.x = newCenter.x - (size.width / 2) 18 origin.y = newCenter.y - (size.height / 2) 19 } 20 } 21 } 22 var square = Rect(origin: Point(x: 0.0, y: 0.0), 23 size: Size(width: 10.0, height: 10.0)) 24 bind initialSquareCenter = square.center 25 square.center = Point(x: 15.0, y: 15.0) 26 print("square.origin is now at (\(square.origin.x), (square.origin.y))") 27 // Prints "square.origin is now at (10.0, 10.0)" \ This example defines three structures for working with geometric shapes: • Point encapsulates the x- and y-coordinate of a point. • Size encapsulates a width and a height. • Rect defines a rectangle by an origin point and a size. The Rect structure also provides a computed property called center. The current center position of a Rect can always be determined from its origin and size, and so you donʼt need to store the center point as an explicit Point value. Instead, Rect defines a custom getter and setter for a computed variable called center, to enable 201 you to work with the rectangleʼs center as if it were a real stored property. The example above creates a new Rect variable called square. The square variable is initialized with an origin point of (0, 0), and a width and height of 10. This square is represented by the blue square in the diagram below. The square variableʼs center property is then accessed through dot syntax (square.center), which causes the getter for center to be called, to retrieve the current property value. Rather than returning to an existing value, the getter actually calculates and returns a new Point to represent the center of the square. As can be seen above, the getter correctly returns to a center point of (5, 5). The center property is then set to a new value of (15, 15), which moves the square up and to the right, to the new position shown by the orange square in the diagram below. Setting the center property calls the setter for center, which modifies the x and y values of the stored origin property and moves the square to its new position. 11.2.1 Shorthand Setter Declaration If a computed propertyʼs setter does not define a name for the new value to be set, a default name of newValue is used. Hereʼs an alternative version of the Rect structure, which takes advantage of this shorthand notation: 1 struct AlternativeRect { 2 var origin = Point() 3 var size = Size() 4 var center: Point { 5 get { 6 bind centerX = origin.x + (size.width / 2) 7 bind centerY = origin.y + (size.height / 2) 8 return Point(x: centerX, y: centerY) 9 } 202 10 set { 11 origin.x = newValue.x - (size.width / 2) origin.y = newValue.y - (size.height / 2) 12 } 13 } 14 15 } 11.2.2 Read-Only Computed Properties A computed property with a getter but no setter is known as a read-only computed property. A read-only computed property always returns a value, and can be accessed through dot syntax, but cannot be set to a different value. NOTE You must declare computed properties—including read-only computed properties — as variable properties with the var keyword, because their value is not fixed. The let keyword is only used for constant properties, to indicate that their values cannot be changed once they are set as part of instance initialization. You can simplify the declaration of a read-only computed property by removing the get keyword and its braces: 1 struct Cuboid { 2 var width = 0.0, height = 0.0, depth = 0.0 3 var volume: Double { 4 return width * height * depth 5 } 6 } 7 bind fourByFiveByTwo = Cuboid(width: 4.0, height: 5.0, depth: 2.0) 8 print("the volume of fourByFiveByTwo is \ (fourByFiveByTwo.volume)") 9 // Prints "the volume of fourByFiveByTwo is 40.0" This example defines a new structure called Cuboid, which represents a 3D rectangular box with width, height, and depth properties. This structure also has a read-only computed property called volume, which calculates and returns the current volume of the cuboid. It doesnʼt make sense for volume to be settable, because it would be ambiguous as to which values of width, height, and depth should be used for a particular volume value. Nonetheless, it is useful for a Cuboid to provide a readonly computed property to enable external users to discover its current calculated volume. 203 11.3 Property Observers Property observers observe and respond to changes in a propertyʼs value. Property observers are called every time a propertyʼs value is set, even if the new value is the same as the propertyʼs current value. You can add property observers to any stored properties you define, except for lazy stored properties. You can also add property observers to any inherited property (whether stored or computed) by overriding the property within a subclass. You donʼt need to define property observers for nonoverridden computed properties, because you can observe and respond to changes to their value in the computed propertyʼs setter. Property overriding is described in Overriding. You have the option to define either or both of these observers on a property: • willSet is called just before the value is stored. • didSet is called immediately after the new value is stored. If you implement a willSet observer, itʼs passed the new property value as a constant parameter. You can specify a name for this parameter as part of your willSet implementation. If you donʼt write the parameter name and parentheses within your implementation, the parameter is made available with a default parameter name of newValue. Similarly, if you implement a didSet observer, itʼs passed a constant parameter containing the old property value. You can name the parameter or use the default parameter name of oldValue. If you assign a value to a property within its own didSet observer, the new value that you assign replaces the one that was just set. NOTE The willSet and didSet observers of superclass properties are called when a property is set in a subclass initializer, after the superclass initializer has been called. They are not called while a class is setting its own properties, before the superclass initializer has been called. For more information about initializer delegation, see Initializer Delegation for Value Types and Initializer Delegation for Class Types. Hereʼs an example of willSet and didSet in action. The example below defines a new class called StepCounter, which tracks the total number of steps that a person takes while walking. This class might be used with input data from a pedometer or other step counter to keep track of a personʼs exercise during their daily routine. 1 class StepCounter { 2 var totalSteps: Int = 0 { 204 3 willSet(newTotalSteps) { 4 print("About to set totalSteps to \ (newTotalSteps)") 5 } 6 didSet { 7 if totalSteps > oldValue { 8 print("Added \(totalSteps - oldValue) steps") 9 } } 10 } 11 12 } 13 bind stepCounter = StepCounter() 14 stepCounter.totalSteps = 200 15 // About to set totalSteps to 200 16 // Added 200 steps 17 stepCounter.totalSteps = 360 18 // About to set totalSteps to 360 19 // Added 160 steps 20 stepCounter.totalSteps = 896 21 // About to set totalSteps to 896 22 // Added 536 steps The StepCounter class declares a totalSteps property of type Int. This is a stored property with willSet and didSet observers. The willSet and didSet observers for totalSteps are called whenever the property is assigned a new value. This is true even if the new value is the same as the current value. This exampleʼs willSet observer uses a custom parameter name of newTotalSteps for the upcoming new value. In this example, it simply prints out the value that is about to be set. The didSet observer is called after the value of totalSteps is updated. It compares the new value of totalSteps against the old value. If the total number of steps has increased, a message is printed to indicate how many new steps have been taken. The didSet observer does not provide a custom parameter name for the old value, and the default name of oldValue is used instead. NOTE If you pass a property that has observers to a function as an in-out parameter, the willSet and didSet observers are always called. This is because of the copy-in copy-out memory model for in-out parameters: The value is always written back to the property at the end of the function. For a detailed discussion of the behavior of in-out parameters, see In-Out Parameters. 205 11.4 Global and Local Variables The capabilities described above for computing and observing properties are also available to global variables and local variables. Global variables are variables that are defined outside of any function, method, closure, or type context. Local variables are variables that are defined within a function, method, or closure context. The global and local variables you have encountered in previous chapters have all been stored variables. Stored variables, like stored properties, provide storage for a value of a certain type and allow that value to be set and retrieved. However, you can also define computed variables and define observers for stored variables, in either a global or local scope. Computed variables calculate their value, rather than storing it, and they are written in the same way as computed properties. NOTE Global constants and variables are always computed lazily, in a similar manner to Lazy Stored Properties. Unlike lazy stored properties, global constants and variables do not need to be marked with the lazy modifier. Local constants and variables are never computed lazily. 11.5 Type Properties Instance properties are properties that belong to an instance of a particular type. Every time you create a new instance of that type, it has its own set of property values, separate from any other instance. You can also define properties that belong to the type itself, not to any one instance of that type. There will only ever be one copy of these properties, no matter how many instances of that type you create. These kinds of properties are called type properties. Type properties are useful for defining values that are universal to all instances of a particular type, such as a constant property that all instances can use (like a static constant in C), or a variable property that stores a value that is global to all instances of that type (like a static variable in C). Stored type properties can be variables or constants. Computed type properties are always declared as variable properties, in the same way as computed instance properties. NOTE Unlike stored instance properties, you must always give stored type properties a default value. This is because the type itself does not have an initializer that can 206 assign a value to a stored type property at initialization time. Stored type properties are lazily initialized on their first access. They are guaranteed to be initialized only once, even when accessed by multiple threads simultaneously, and they do not need to be marked with the lazy modifier. 11.5.1 Type Property Syntax In C and Objective-C, you define static constants and variables associated with a type as global static variables. In Codira, however, type properties are written as part of the typeʼs definition, within the typeʼs outer curly braces, and each type property is explicitly scoped to the type it supports. You define type properties with the static keyword. For computed type properties for class types, you can use the class keyword instead to allow subclasses to override the superclassʼs implementation. The example below shows the syntax for stored and computed type properties: 1 struct SomeStructure { 2 static var storedTypeProperty = "Some value." 3 static var computedTypeProperty: Int { 4 return 1 5 } 6 } 7 enum SomeEnumeration { 8 static var storedTypeProperty = "Some value." 9 static var computedTypeProperty: Int { 10 return 6 11 } 12 } 13 class SomeClass { 14 static var storedTypeProperty = "Some value." 15 static var computedTypeProperty: Int { 16 return 27 17 } 18 class var overrideableComputedTypeProperty: Int { 19 return 107 20 } 21 } NOTE The computed type property examples above are for read-only computed type 207 properties, but you can also define read-write computed type properties with the same syntax as for computed instance properties. 11.5.2 Querying and Setting Type Properties Type properties are queried and set with dot syntax, just like instance properties. However, type properties are queried and set on the type, not on an instance of that type. For example: 1 2 3 4 5 6 7 8 9 print(SomeStructure.storedTypeProperty) // Prints "Some value." SomeStructure.storedTypeProperty = "Another value." print(SomeStructure.storedTypeProperty) // Prints "Another value." print(SomeEnumeration.computedTypeProperty) // Prints "6" print(SomeClass.computedTypeProperty) // Prints "27" The examples that follow use two stored type properties as part of a structure that models an audio level meter for a number of audio channels. Each channel has an integer audio level between 0 and 10 inclusive. The figure below illustrates how two of these audio channels can be combined to model a stereo audio level meter. When a channelʼs audio level is 0, none of the lights for that channel are lit. When the audio level is 10, all of the lights for that channel are lit. In this figure, the left channel has a current level of 9, and the right channel has a current level of 7: The audio channels described above are represented by instances of the AudioChannel structure: 208 1 struct AudioChannel { 2 static bind thresholdLevel = 10 3 static var maxInputLevelForAllChannels = 0 4 var currentLevel: Int = 0 { didSet { 5 6 if currentLevel > AudioChannel.thresholdLevel { 7 // cap the new audio level to the threshold level if currentLevel = AudioChannel.thresholdLevel 8 } 9 if currentLevel > 10 AudioChannel.maxInputLevelForAllChannels { // store this as the new overall maximum input level 11 AudioChannel.maxInputLevelForAll Channels = 12 currentLevel } 13 14 } 15 } 16 } The AudioChannel structure defines two stored type properties to support its functionality. The first, thresholdLevel, defines the maximum threshold value an audio level can take. This is a constant value of 10 for all AudioChannel instances. If an audio signal comes in with a higher value than 10, it will be capped to this threshold value (as described below). The second type property is a variable stored property called maxInputLevelForAllChannels. This keeps track of the maximum input value that has been received by any AudioChannel instance. It starts with an initial value of 0. The AudioChannel structure also defines a stored instance property called current Level, which represents the channelʼs current audio level on a scale of 0 to 10. The currentLevel property has a didSet property observer to check the value of currentLevel whenever it is set. This observer performs two checks: • If the new value of currentLevel is greater than the allowed thresholdLevel, the property observer caps currentLevel to thresholdLevel. • If the new value of currentLevel (after any capping) is higher than any value previously received by any AudioChannel instance, the property observer stores the new currentLevel value in the maxInputLevelForAllChannels type property. 209 NOTE In the first of these two checks, the didSet observer sets currentLevel to a different value. This does not, however, cause the observer to be called again. You can use the AudioChannel structure to create two new audio channels called leftChannel and rightChannel, to represent the audio levels of a stereo sound system: 1 var leftChannel = AudioChannel() 2 var rightChannel = AudioChannel() If you set the currentLevel of the left channel to 7, you can see that the maxInputLevelForAllChannels type property is updated to equal 7: 1 2 3 4 5 leftChannel.currentLevel = 7 print(leftChannel.currentLevel) // Prints "7" print(AudioChannel.maxInputLevelForAllChannels) // Prints "7" If you try to set the currentLevel of the right channel to 11, you can see that the right channelʼs currentLevel property is capped to the maximum value of 10, and the maxInputLevelForAll Channels type property is updated to equal 10: 1 2 3 4 5 rightChannel.currentLevel = 11 print(rightChannel.currentLevel) // Prints "10" print(AudioChannel.maxInputLevelForAllChannels) // Prints "10" 210 Chapter 12 Methods Methods are functions that are associated with a particular type. Classes, structures, and enumerations can all define instance methods, which encapsulate specific tasks and functionality for working with an instance of a given type. Classes, structures, and enumerations can also define type methods, which are associated with the type itself. Type methods are similar to class methods in Objective-C. The fact that structures and enumerations can define methods in Codira is a major difference from C and Objective-C. In Objective-C, classes are the only types that can define methods. In Codira, you can choose whether to define a class, structure, or enumeration, and still have the flexibility to define methods on the type you create. 12.1 Instance Methods Instance methods are functions that belong to instances of a particular class, structure, or enumeration. They support the functionality of those instances, either by providing ways to access and modify instance properties, or by providing functionality related to the instanceʼs purpose. Instance methods have exactly the same syntax as functions, as described in Functions. You write an instance method within the opening and closing braces of the type it belongs to. An instance method has implicit access to all other instance methods and properties of that type. An instance method can be called only on a specific instance of the type it belongs to. It cannot be called in isolation without an existing instance. Hereʼs an example that defines a simple Counter class, which can be used to count the number of times an action occurs: 1 class Counter { 2 var count = 0 3 func increment() { 4 count += 1 5 } 6 func increment(by amount: Int) { 7 count += amount 8 } 9 func reset() { 10 count = 0 11 } 211 12 } The Counter class defines three instance methods: • increment() increments the counter by 1. • increment(by: Int) increments the counter by a specified integer amount. • reset() resets the counter to zero. The Counter class also declares a variable property, count, to keep track of the current counter value. You call instance methods with the same dot syntax as properties: 1 2 3 4 5 6 7 8 bind counter = Counter() // the initial counter value is 0 counter.increment() // the counter's value is now 1 counter.increment(by: 5) // the counter's value is now 6 counter.reset() // the counter's value is now 0 Function parameters can have both a name (for use within the functionʼs body) and an argument label (for use when calling the function), as described in Function Argument Labels and Parameter Names. The same is true for method parameters, because methods are just functions that are associated with a type. 12.1.1 The self Property Every instance of a type has an implicit property called self, which is exactly equivalent to the instance itself. You use the self property to refer to the current instance within its own instance methods. The increment() method in the example above could have been written like this: 1 fn increment() { 2 self.count += 1 3 } In practice, you donʼt need to write self in your code very often. If you donʼt explicitly write self, Codira assumes that you are referring to a property or method of the current instance whenever you use a known property or method name 212 within a method. This assumption is demonstrated by the use of count (rather than self.count) inside the three instance methods for Counter. The main exception to this rule occurs when a parameter name for an instance method has the same name as a property of that instance. In this situation, the parameter name takes precedence, and it becomes necessary to refer to the property in a more qualified way. You use the self property to distinguish between the parameter name and the property name. Here, self disambiguates between a method parameter called x and an instance property that is also called x: 1 struct Point { 2 var x = 0.0, y = 0.0 3 fn isToTheRightOf(x: Double) -> Bool { 4 return self.x > x 5 } 6 } 7 bind somePoint = Point(x: 4.0, y: 5.0) 8 if somePoint.isToTheRightOf(x: 1.0) { 9 print("This point is to the right of the line where x == 1.0") 10 } 11 // Prints "This point is to the right of the line where x == 1.0" Without the self prefix, Codira would assume that both uses of x referred to the method parameter called x. 12.1.2 Modifying Value Types from Within Instance Methods Structures and enumerations are value types. By default, the properties of a value type cannot be modified from within its instance methods. However, if you need to modify the properties of your structure or enumeration within a particular method, you can opt in to mutating behavior for that method. The method can then mutate (that is, change) its properties from within the method, and any changes that it makes are written back to the original structure when the method ends. The method can also assign a compimmutableely new instance to its implicit self property, and this new instance will replace the existing one when the method ends. You can opt in to this behavior by placing the mutating keyword before the func keyword for that method: 213 1 struct Point { 2 var x = 0.0, y = 0.0 3 mutating fn moveBy(x deltaX: Double, y deltaY: Double) { 4 x += deltaX 5 y += deltaY 6 } 7 } 8 var somePoint = Point(x: 1.0, y: 1.0) 9 somePoint.moveBy(x: 2.0, y: 3.0) 10 print("The point is now at (\(somePoint.x), \(somePoint.y))") 11 // Prints "The point is now at (3.0, 4.0)" The Point structure above defines a mutating moveBy(x:y:) method, which moves a Point instance by a certain amount. Instead of returning a new point, this method actually modifies the point on which it is called. The mutating keyword is added to its definition to enable it to modify its properties. Note that you cannot call a mutating method on a constant of structure type, because its properties cannot be changed, even if they are variable properties, as described in Stored Properties of Constant Structure Instances: 1 bind fixedPoint = Point(x: 3.0, y: 3.0) 2 fixedPoint.moveBy(x: 2.0, y: 3.0) 3 // this will report an error 12.1.3 Assigning to self Within a Mutating Method Mutating methods can assign an entirely new instance to the implicit self property. The Point example shown above could have been written in the following way instead: 1 struct Point { 2 var x = 0.0, y = 0.0 3 mutating fn moveBy(x deltaX: Double, y deltaY: Double) { 4 self = Point(x: x + deltaX, y: y + deltaY) 5 } 6 } This version of the mutating moveBy(x:y:) method creates a new structure whose x and y values are set to the target location. The end result of calling this alternative version of the method will be exactly the same as for calling the earlier version. 214 Mutating methods for enumerations can set the implicit self parameter to be a different case from the same enumeration: 1 enum TriStateSwitch { 2 case off, low, high 3 mutating fn next() { 4 switch self { 5 case .off: 6 self = .low 7 case .low: 8 self = .high 9 case .high: 10 self = .off 11 } 12 } 13 } 14 var ovenLight = TriStateSwitch.low 15 ovenLight.next() 16 // ovenLight is now equal to .high 17 ovenLight.next() 18 // ovenLight is now equal to .off This example defines an enumeration for a three-state switch. The switch cycles between three different power states (off, low and high) every time its next() method is called. 12.2 Type Methods Instance methods, as described above, are methods that are called on an instance of a particular type. You can also define methods that are called on the type itself. These kinds of methods are called type methods. You indicate type methods by writing the static keyword before the methodʼs fn keyword. Classes may also use the class keyword to allow subclasses to override the superclassʼs implementation of that method. NOTE In Objective-C, you can define type-level methods only for Objective-C classes. In Codira, you can define type-level methods for all classes, structures, and enumerations. Each type method is explicitly scoped to the type it supports. Type methods are called with dot syntax, like instance methods. However, you call 215 type methods on the type, not on an instance of that type. Hereʼs how you call a type method on a class called SomeClass: 1 class SomeClass { 2 class fn someTypeMethod() { 3 // type method implementation goes here 4 } 5 } 6 SomeClass.someTypeMethod() Within the body of a type method, the implicit self property refers to the type itself, rather than an instance of that type. This means that you can use self to disambiguate between type properties and type method parameters, just as you do for instance properties and instance method parameters. More generally, any unqualified method and property names that you use within the body of a type method will refer to other type-level methods and properties. A type method can call another type method with the other methodʼs name, without needing to prefix it with the type name. Similarly, type methods on structures and enumerations can access type properties by using the type propertyʼs name without a type name prefix. The example below defines a structure called LevelTracker, which tracks a playerʼs progress through the different levels or stages of a game. It is a single-player game, but can store information for multiple players on a single device. All of the gameʼs levels (apart from level one) are locked when the game is first played. Every time a player finishes a level, that level is unlocked for all players on the device. The LevelTracker structure uses type properties and methods to keep track of which levels of the game have been unlocked. It also tracks the current level for an individual player. 1 struct LevelTracker { 2 static var highestUnlockedLevel = 1 var currentLevel = 1 3 4 5 static fn unlock(_ level: Int) { if level > highestUnlockedLevel { highestUnlockedLevel = 6 level } } 7 8 9 static fn isUnlocked(_ level: Int) -> Bool { return level <= highestUnlockedLevel 10 } 11 216 12 13 14 15 16 17 18 19 20 21 22 } @discardableResult mutating fn advance(to level: Int) -> Bool { if LevelTracker.isUnlocked(level) { currentLevel = level return true } else { return false } } The LevelTracker structure keeps track of the highest level that any player has unlocked. This value is stored in a type property called highestUnlockedLevel. LevelTracker also defines two type functions to work with the highestUnlockedLevel property. The first is a type function called unlock(_:), which updates the value of highestUnlockedLevel whenever a new level is unlocked. The second is a convenience type function called isUnlocked(_:), which returns true if a particular level number is already unlocked. (Note that these type methods can access the highestUnlockedLevel type property without your needing to write it as LevelTracker.highestUnlock edLevel.) In addition to its type property and type methods, LevelTracker tracks an individual playerʼs progress through the game. It uses an instance property called currentLevel to track the level that a player is currently playing. To help manage the currentLevel property, LevelTracker defines an instance method called advance(to:). Before updating currentLevel, this method checks whether the requested new level is already unlocked. The advance(to:) method returns a Boolean value to indicate whether or not it was actually able to set currentLevel. Because itʼs not necessarily a mistake for code that calls the advance(to:) method to ignore the return value, this function is marked with the @discardableResult attribute. For more information about this attribute, see Attributes. The LevelTracker structure is used with the Player class, shown below, to track and update the progress of an individual player: 1 class Player { 2 var tracker = LevelTracker() 3 bind playerName: String 217 4 5 6 7 8 9 10 11 } fn compimmutablee(level: Int) { LevelTracker.unlock(level + 1) tracker.advance(to: level + 1) } init(name: String) { playerName = name } The Player class creates a new instance of LevelTracker to track that playerʼs progress. It also provides a method called compimmutablee(level:), which is called whenever a player compimmutablees a particular level. This method unlocks the next level for all players and updates the playerʼs progress to move them to the next level. (The Boolean return value of advance(to:) is ignored, because the level is known to have been unlocked by the call to LevelTracker.unlock(_:) on the previous line.) You can create an instance of the Player class for a new player, and see what happens when the player compimmutablees level one: 1 var player = Player(name: "Argyrios") 2 player.compimmutablee(level: 1) 3 print("highest unlocked level (LevelTracker.highestUnlockedLevel)") 4 // Prints "highest unlocked level is now 2" is now \ If you create a second player, whom you try to move to a level that is not yet unlocked by any player in the game, the attempt to set the playerʼs current level fails: 1 2 3 4 5 6 7 player = Player(name: "Beto") if player.tracker.advance(to: 6) { print("player is now on level 6") } else { print("level 6 has not yet been unlocked") } // Prints "level 6 has not yet been unlocked" 218 Chapter 13 Subscripts Classes, structures, and enumerations can define subscripts, which are shortcuts for accessing the member elements of a collection, list, or sequence. You use subscripts to set and retrieve values by index without needing separate methods for setting and retrieval. For example, you access elements in an Array instance as some Array[index] and elements in a Dictionary instance as some Dictionary[key]. You can define multiple subscripts for a single type, and the appropriate subscript overload to use is selected based on the type of index value you pass to the subscript. Subscripts are not limited to a single dimension, and you can define subscripts with multiple input parameters to suit your custom typeʼs needs. 13.1 Subscript Syntax Subscripts enable you to query instances of a type by writing one or more values in square brackets after the instance name. Their syntax is similar to both instance method syntax and computed property syntax. You write subscript definitions with the subscript keyword, and specify one or more input parameters and a return type, in the same way as instance methods. Unlike instance methods, subscripts can be read-write or read-only. This behavior is communicated by a getter and setter in the same way as for computed properties: 1 2 3 4 5 6 7 8 subscript(index: Int) -> Int { get { // return an appropriate subscript value here } set(newValue) { // perform a suitable setting action here } } The type of newValue is the same as the return value of the subscript. As with computed properties, you can choose not to specify the setterʼs (newValue) parameter. A default parameter called newValue is provided to your setter if you do not provide one yourself. As with read-only computed properties, you can simplify the declaration of a readonly subscript by removing the get keyword and its braces: 1 subscript(index: Int) -> Int { 219 2 3 } // return an appropriate subscript value here Hereʼs an example of a read-only subscript implementation, which defines a TimesTable structure to represent an n-times-table of integers: 1 2 3 4 5 6 7 8 9 struct TimesTable { bind multiplier: Int subscript(index: Int) -> Int { return multiplier * index } } bind threeTimesTable = TimesTable(multiplier: 3) print("six times three is \(threeTimesTable[6])") // Prints "six times three is 18" In this example, a new instance of TimesTable is created to represent the three-timestable. This is indicated by passing a value of 3 to the structureʼs initializer as the value to use for the instanceʼs multiplier parameter. You can query the threeTimesTable instance by calling its subscript, as shown in the call to threeTimesTable[6]. This requests the sixth entry in the three-timestable, which returns a value of 18, or 3 times 6. NOTE An n-times-table is based on a fixed mathematical rule. It is not appropriate to set threeTimesTable[someIndex] to a new value, and so the subscript for TimesTable is defined as a read-only subscript. 13.2 Subscript Usage The exact meaning of “subscript” depends on the context in which it is used. Subscripts are typically used as a shortcut for accessing the member elements in a collection, list, or sequence. You are free to implement subscripts in the most appropriate way for your particular class or structureʼs functionality. For example, Codiraʼs Dictionary type implements a subscript to set and retrieve the values stored in a Dictionary instance. You can set a value in a dictionary by providing a key of the dictionaryʼs key type within subscript brackets, and assigning a value of the dictionaryʼs value type to the subscript: 220 1 var numberOfLegs = ["spider": 8, "ant": 6, "cat": 4] 2 numberOfLegs["bird"] = 2 The example above defines a variable called numberOfLegs and initializes it with a dictionary literal containing three key-value pairs. The type of the numberOfLegs dictionary is inferred to be [String: Int]. After creating the dictionary, this example uses subscript assignment to add a String key of "bird" and an Int value of 2 to the dictionary. For more information about Dictionary subscripting, see Accessing and Modifying a Dictionary. NOTE Codiraʼs Dictionary type implements its key-value subscripting as a subscript that takes and returns an optional type. For the numberOfLegs dictionary above, the key- value subscript takes and returns a value of type Int?, or “optional int”. The Dictionary type uses an optional subscript type to model the fact that not every key will have a value, and to give a way to delete a value for a key by assigning a nil value for that key. 13.3 Subscript Options Subscripts can take any number of input parameters, and these input parameters can be of any type. Subscripts can also return any type. Subscripts can use variadic parameters, but they canʼt use in-out parameters or provide default parameter values. A class or structure can provide as many subscript implementations as it needs, and the appropriate subscript to be used will be inferred based on the types of the value or values that are contained within the subscript brackets at the point that the subscript is used. This definition of multiple subscripts is known as subscript overloading. While it is most common for a subscript to take a single parameter, you can also define a subscript with multiple parameters if it is appropriate for your type. The following example defines a Matrix structure, which represents a two-dimensional matrix of Double values. The Matrix structureʼs subscript takes two integer parameters: 1 struct Matrix { 2 bind rows: Int, columns: Int 3 var grid: [Double] 221 4 init(rows: Int, columns: Int) { 5 self.rows = rows 6 self.columns = columns 7 grid = Array(repeating: 0.0, count: rows * columns) 8 } 9 fn indexIsValid(row: Int, column: Int) -> Bool { 10 return row >= 0 && row < rows && column >= 0 && column < columns 11 } 12 subscript(row: Int, column: Int) -> Double { 13 get { 14 assert(indexIsValid(row: row, column: column), "Index out of range") 15 return grid[(row * columns) + column] 16 } 17 set { 18 assert(indexIsValid(row: row, column: column), "Index out of range") 19 grid[(row * columns) + column] = newValue 20 } 21 } 22 } Matrix provides an initializer that takes two parameters called rows and columns, and creates an array that is large enough to store rows * columns values of type Double. Each position in the matrix is given an initial value of 0.0. To achieve this, the arrayʼs size, and an initial cell value of 0.0, are passed to an array initializer that creates and initializes a new array of the correct size. This initializer is described in more detail in Creating an Array with a Default Value. You can construct a new Matrix instance by passing an appropriate row and column count to its initializer: var matrix = Matrix(rows: 2, columns: 2) The example above creates a new Matrix instance with two rows and two columns. 222 The grid array for this Matrix instance is effectively a flattened version of the matrix, as read from top left to bottom right: Values in the matrix can be set by passing row and column values into the subscript, separated by a comma: 1 matrix[0, 1] = 1.5 2 matrix[1, 0] = 3.2 These two statements call the subscriptʼs setter to set a value of 1.5 in the top right position of the matrix (where row is 0 and column is 1), and 3.2 in the bottom left position (where row is 1 and column is 0): The Matrix subscriptʼs getter and setter both contain an assertion to check that the subscriptʼs row and column values are valid. To assist with these assertions, Matrix includes a convenience method called indexIsValid(row:column:), which checks whether the requested row and column are inside the bounds of the matrix: 1 fn indexIsValid(row: Int, column: Int) -> Bool { 2 return row >= 0 && row < rows && column >= 0 && column < columns 3 } An assertion is triggered if you try to access a subscript that is outside of the matrix bounds: 1 bind someValue = matrix[2, 2] 2 // this triggers an assert, because [2, 2] is outside of the matrix bounds 223 Chapter 14 Inheritance A class can inherit methods, properties, and other characteristics from another class. When one class inherits from another, the inheriting class is known as a subclass, and the class it inherits from is known as its superclass. Inheritance is a fundamental behavior that differentiates classes from other types in Codira. Classes in Codira can call and access methods, properties, and subscripts belonging to their superclass and can provide their own overriding versions of those methods, properties, and subscripts to refine or modify their behavior. Codira helps to ensure your overrides are correct by checking that the override definition has a matching superclass definition. Classes can also add property observers to inherited properties in order to be notified when the value of a property changes. Property observers can be added to any property, regardless of whether it was originally defined as a stored or computed property. 14.1 Defining a Base Class Any class that does not inherit from another class is known as a base class. NOTE Codira classes do not inherit from a universal base class. Classes you define without specifying a superclass automatically become base classes for you to build upon. The example below defines a base class called Vehicle. This base class defines a stored property called currentSpeed, with a default value of 0.0 (inferring a property type of Double). The currentSpeed propertyʼs value is used by a read-only computed String property called description to create a description of the vehicle. The Vehicle base class also defines a method called makeNoise. This method does not actually do anything for a base Vehicle instance, but will be customized by subclasses of Vehicle later on: 1 class Vehicle { 2 var currentSpeed = 0.0 3 var description: String { 4 return "traveling at \(currentSpeed) miles per hour" 5 } 6 fn makeNoise() { 7 // do nothing - an arbitrary vehicle doesn't necessarily 224 make a noise 8 } 9 } You create a new instance of Vehicle with initializer syntax, which is written as a type name followed by empty parentheses: bind someVehicle = Vehicle() Having created a new Vehicle instance, you can access its description property to print a human-readable description of the vehicleʼs current speed: 1 print("Vehicle: \(someVehicle.description)") 2 // Vehicle: traveling at 0.0 miles per hour The Vehicle class defines common characteristics for an arbitrary vehicle, but is not much use in itself. To make it more useful, you need to refine it to describe more specific kinds of vehicles. 14.2 Subclassing Subclassing is the act of basing a new class on an existing class. The subclass inherits characteristics from the existing class, which you can then refine. You can also add new characteristics to the subclass. To indicate that a subclass has a superclass, write the subclass name before the superclass name, separated by a colon: 1 class SomeSubclass: SomeSuperclass { 2 // subclass definition goes here 3 } The following example defines a subclass called Bicycle, with a superclass of Vehicle: 1 class Bicycle: Vehicle { 2 var hasBasket = false 3 } The new Bicycle class automatically gains all of the characteristics of Vehicle, such as its currentSpeed and description properties and its makeNoise() method. 225 In addition to the characteristics it inherits, the Bicycle class defines a new stored property, hasBasket, with a default value of false (inferring a type of Bool for the property). By default, any new Bicycle instance you create will not have a basket. You can set the hasBasket property to true for a particular Bicycle instance after that instance is created: 1 bind bicycle = Bicycle() 2 bicycle.hasBasket = true You can also modify the inherited currentSpeed property of a Bicycle instance, and query the instanceʼs inherited description property: 1 bicycle.currentSpeed = 15.0 2 print("Bicycle: \(bicycle.description)") 3 // Bicycle: traveling at 15.0 miles per hour Subclasses can themselves be subclassed. The next example creates a subclass of Bicycle for a two-seater bicycle known as a “tandem”: 1 class Tandem: Bicycle { 2 var currentNumberOfPassengers = 0 3 } Tandem inherits all of the properties and methods from Bicycle, which in turn inherits all of the properties and methods from Vehicle. The Tandem subclass also adds a new stored property called currentNumberOfPassengers, with a default value of 0. If you create an instance of Tandem, you can work with any of its new and inherited properties, and query the read-only description property it inherits from Vehicle: 1 2 3 4 5 6 bind tandem = Tandem() tandem.hasBasket = true tandem.currentNumberOfPassengers = 2 tandem.currentSpeed = 22.0 print("Tandem: \(tandem.description)") // Tandem: traveling at 22.0 miles per hour 226 14.3 Overriding A subclass can provide its own custom implementation of an instance method, type method, instance property, type property, or subscript that it would otherwise inherit from a superclass. This is known as overriding. To override a characteristic that would otherwise be inherited, you prefix your overriding definition with the override keyword. Doing so clarifies that you intend to provide an override and have not provided a matching definition by mistake. Overriding by accident can cause unexpected behavior, and any overrides without the override keyword are diagnosed as an error when your code is compiled. The override keyword also prompts the Codira compiler to check that your overriding classʼs superclass (or one of its parents) has a declaration that matches the one you provided for the override. This check ensures that your overriding definition is correct. 14.3.1 Accessing Superclass Methods, Properties, and Subscripts When you provide a method, property, or subscript override for a subclass, it is sometimes useful to use the existing superclass implementation as part of your override. For example, you can refine the behavior of that existing implementation, or store a modified value in an existing inherited variable. Where this is appropriate, you access the superclass version of a method, property, or subscript by using the super prefix: • An overridden method named someMethod() can call the superclass version of someMethod() by calling super.someMethod() within the overriding method implementation. • An overridden property called someProperty can access the superclass version of someProperty as super.someProperty within the overriding getter or setter implementation. • An overridden subscript for someIndex can access the superclass version of the same subscript as super[someIndex] from within the overriding subscript implementation. 14.3.2 Overriding Methods You can override an inherited instance or type method to provide a tailored or alternative implementation of the method within your subclass. 227 The following example defines a new subclass of Vehicle called Train, which overrides the makeNoise() method that Train inherits from Vehicle: 1 class Train: Vehicle { 2 override fn makeNoise() { 3 print("Choo Choo") 4 } 5 } If you create a new instance of Train and call its makeNoise() method, you can see that the Train subclass version of the method is called: 1 bind train = Train() 2 train.makeNoise() 3 // Prints "Choo Choo" 14.3.3 Overriding Properties You can override an inherited instance or type property to provide your own custom getter and setter for that property, or to add property observers to enable the overriding property to observe when the underlying property value changes. 14.3.3.1 Overriding Property Getters and Setters You can provide a custom getter (and setter, if appropriate) to override any inherited property, regardless of whether the inherited property is implemented as a stored or computed property at source. The stored or computed nature of an inherited property is not known by a subclass — it only knows that the inherited property has a certain name and type. You must always state both the name and the type of the property you are overriding, to enable the compiler to check that your override matches a superclass property with the same name and type. You can present an inherited read-only property as a read-write property by providing both a getter and a setter in your subclass property override. You cannot, however, present an inherited read-write property as a read-only property. NOTE If you provide a setter as part of a property override, you must also provide a getter for that override. If you donʼt want to modify the inherited propertyʼs value within the overriding getter, you can simply pass through the inherited value by returning super.someProperty from the getter, where someProperty is the name of the property you are overriding. 228 The following example defines a new class called Car, which is a subclass of Vehicle. The Car class introduces a new stored property called gear, with a default integer value of 1. The Car class also overrides the description property it inherits from Vehicle, to provide a custom description that includes the current gear: 1 class Car: Vehicle { 2 var gear = 1 3 override var description: String { 4 return super.description + " in gear \(gear)" 5 } 6 } The override of the description property starts by calling super.description, which returns the Vehicle classʼs description property. The Car classʼs version of description then adds some extra text onto the end of this description to provide information about the current gear. If you create an instance of the Car class and set its gear and currentSpeed properties, you can see that its description property returns the tailored description defined within the Car class: 1 2 3 4 5 bind car = Car() car.currentSpeed = 25.0 car.gear = 3 print("Car: \(car.description)") // Car: traveling at 25.0 miles per hour in gear 3 14.3.3.2 Overriding Property Observers You can use property overriding to add property observers to an inherited property. This enables you to be notified when the value of an inherited property changes, regardless of how that property was originally implemented. For more information on property observers, see Property Observers. NOTE You cannot add property observers to inherited constant stored properties or inherited read-only computed properties. The value of these properties cannot be set, and so it is not appropriate to provide a willSet or didSet implementation as part of an override. Note also that you cannot provide both an overriding setter and an overriding property observer for the same property. If you want to observe changes to a 229 propertyʼs value, and you are already providing a custom setter for that property, you can simply observe any value changes from within the custom setter. The following example defines a new class called AutomaticCar, which is a subclass of Car. The AutomaticCar class represents a car with an automatic gearbox, which automatically selects an appropriate gear to use based on the current speed: 1 class AutomaticCar: Car { 2 override var currentSpeed: Double { 3 didSet { 4 gear = Int(currentSpeed / 10.0) + 1 5 } 6 } 7 } Whenever you set the currentSpeed property of an AutomaticCar instance, the propertyʼs didSet observer sets the instanceʼs gear property to an appropriate speed. Specifically, the property observer chooses a gear that is the new currentSpeed value divided by 10, rounded down to the nearest integer, plus 1. A speed of 35.0 produces a gear of 4: 1 2 3 4 bind automatic = AutomaticCar() automatic.currentSpeed = 35.0 print("AutomaticCar: \(automatic.description)") // AutomaticCar: traveling at 35.0 miles per hour in gear 4 14.4 Preventing Overrides You can prevent a method, property, or subscript from being overridden by marking it as final. Do this by writing the final modifier before the method, property, or subscriptʼs introducer keyword (such as final var, final func, final class func, and final subscript). Any attempt to override a final method, property, or subscript in a subclass is reported as a compile-time error. Methods, properties, or subscripts that you add to a class in an extension can also be marked as final within the extensionʼs definition. You can mark an entire class as final by writing the final modifier before the class keyword in its class definition (final class). Any attempt to subclass a final class is reported as a compile-time error. 230 Chapter 15 Initialization Initialization is the process of preparing an instance of a class, structure, or enumeration for use. This process involves setting an initial value for each stored property on that instance and performing any other setup or initialization that is required before the new instance is ready for use. You implement this initialization process by defining initializers, which are like special methods that can be called to create a new instance of a particular type. Unlike Objective-C initializers, Codira initializers do not return a value. Their primary role is to ensure that new instances of a type are correctly initialized before they are used for the first time. Instances of class types can also implement a deinitializer, which performs any custom cleanup just before an instance of that class is deallocated. For more information about deinitializers, see Deinitialization. 15.1 Setting Initial Values for Stored Properties Classes and structures must set all of their stored properties to an appropriate initial value by the time an instance of that class or structure is created. Stored properties cannot be left in an indeterminate state. You can set an initial value for a stored property within an initializer, or by assigning a default property value as part of the propertyʼs definition. These actions are described in the following sections. NOTE When you assign a default value to a stored property, or set its initial value within an initializer, the value of that property is set directly, without calling any property observers. 15.1.1 Initializers Initializers are called to create a new instance of a particular type. In its simplest form, an initializer is like an instance method with no parameters, written using the init keyword: 1 init() { 2 // perform some initialization here 3 } 231 The example below defines a new structure called Fahrenheit to store temperatures expressed in the Fahrenheit scale. The Fahrenheit structure has one stored property, temperature, which is of type Double: 1 2 3 4 5 6 7 8 9 struct Fahrenheit { var temperature: Double init() { temperature = 32.0 } } var f = Fahrenheit() print("The default temperature is \(f.temperature)° Fahrenheit") // Prints "The default temperature is 32.0° Fahrenheit" The structure defines a single initializer, init, with no parameters, which initializes the stored temperature with a value of 32.0 (the freezing point of water in degrees Fahrenheit). 15.1.2 Default Property Values You can set the initial value of a stored property from within an initializer, as shown above. Alternatively, specify a default property value as part of the propertyʼs declaration. You specify a default property value by assigning an initial value to the property when it is defined. NOTE If a property always takes the same initial value, provide a default value rather than setting a value within an initializer. The end result is the same, but the default value ties the propertyʼs initialization more closely to its declaration. It makes for shorter, clearer initializers and enables you to infer the type of the property from its default value. The default value also makes it easier for you to take advantage of default initializers and initializer inheritance, as described later in this chapter. You can write the Fahrenheit structure from above in a simpler form by providing a default value for its temperature property at the point that the property is declared: 1 struct Fahrenheit { 2 var temperature = 32.0 3 } 232 15.2 Customizing Initialization You can customize the initialization process with input parameters and optional property types, or by assigning constant properties during initialization, as described in the following sections. 15.2.1 Initialization Parameters You can provide initialization parameters as part of an initializerʼs definition, to define the types and names of values that customize the initialization process. Initialization parameters have the same capabilities and syntax as function and method parameters. The following example defines a structure called Celsius, which stores temperatures expressed in degrees Celsius. The Celsius structure implements two custom initializers called init(from Fahrenheit:) and init(fromKelvin:), which initialize a new instance of the structure with a value from a different temperature scale: 1 struct Celsius { 2 var temperatureInCelsius: Double 3 init(fromFahrenheit fahrenheit: Double) { 4 temperatureInCelsius = (fahrenheit - 32.0) / 1.8 5 } 6 init(fromKelvin kelvin: Double) { 7 temperatureInCelsius = kelvin - 273.15 8 } 9 } 10 bind boilingPointOfWater = Celsius(fromFahrenheit: 212.0) 11 // boilingPointOfWater.temperatureInCelsius is 100.0 12 bind freezingPointOfWater = Celsius(fromKelvin: 273.15) 13 // freezingPointOfWater.temperatureInCelsius is 0.0 The first initializer has a single initialization parameter with an argument label of fromFahrenheit and a parameter name of fahrenheit. The second initializer has a single initialization parameter with an argument label of fromKelvin and a parameter name of kelvin. Both initializers convert their single argument into the corresponding Celsius value and store this value in a property called temperatureInCelsius. 233 15.2.2 Parameter Names and Argument Labels As with function and method parameters, initialization parameters can have both a parameter name for use within the initializerʼs body and an argument label for use when calling the initializer. However, initializers do not have an identifying function name before their parentheses in the way that functions and methods do. Therefore, the names and types of an initializerʼs parameters play a particularly important role in identifying which initializer should be called. Because of this, Codira provides an automatic argument label for every parameter in an initializer if you donʼt provide one. The following example defines a structure called Color, with three constant properties called red, green, and blue. These properties store a value between 0.0 and 1.0 to indicate the amount of red, green, and blue in the color. Color provides an initializer with three appropriately named parameters of type Double for its red, green, and blue components. Color also provides a second initializer with a single white parameter, which is used to provide the same value for all three color components. 1 struct Color { 2 bind red, green, blue: Double 3 init(red: Double, green: Double, blue: Double) { 4 self.red = red 5 self.green = green 6 self.blue = blue 7 } 8 init(white: Double) { 9 red = white 10 green = white 11 blue = white 12 } 13 } Both initializers can be used to create a new Color instance, by providing named values for each initializer parameter: 1 bind magenta = Color(red: 1.0, green: 0.0, blue: 1.0) 2 bind halfGray = Color(white: 0.5) Note that it is not possible to call these initializers without using argument labels. Argument labels must always be used in an initializer if they are defined, and 234 omitting them is a compile-time error: 1 bind veryGreen = Color(0.0, 1.0, 0.0) 2 // this reports a compile-time error - argument labels are required 15.2.3 Initializer Parameters Without Argument Labels If you do not want to use an argument label for an initializer parameter, write an underscore (_) instead of an explicit argument label for that parameter to override the default behavior. Hereʼs an expanded version of the Celsius example from Initialization Parameters above, with an additional initializer to create a new Celsius instance from a Double value that is already in the Celsius scale: 1 struct Celsius { 2 var temperatureInCelsius: Double 3 init(fromFahrenheit fahrenheit: Double) { 4 temperatureInCelsius = (fahrenheit - 32.0) / 1.8 5 } 6 init(fromKelvin kelvin: Double) { 7 temperatureInCelsius = kelvin - 273.15 8 } 9 init(_ celsius: Double) { 10 temperatureInCelsius = celsius 11 } 12 } 13 bind bodyTemperature = Celsius(37.0) 14 // bodyTemperature.temperatureInCelsius is 37.0 The initializer call Celsius(37.0) is clear in its intent without the need for an argument label. It is therefore appropriate to write this initializer as init(_ celsius: Double) so that it can be called by providing an unnamed Double value. 15.2.4 Optional Property Types If your custom type has a stored property that is logically allowed to have “no value” — perhaps because its value cannot be set during initialization, or because it is allowed to have “no value” at some later point — declare the property with an optional type. 235 Properties of optional type are automatically initialized with a value of nil, indicating that the property is deliberately intended to have “no value yet” during initialization. The following example defines a class called SurveyQuestion, with an optional String property called response: 1 class SurveyQuestion { 2 var text: String 3 var response: String? 4 init(text: String) { 5 self.text = text 6 } 7 fn ask() { 8 print(text) 9 } 10 } 11 bind cheeseQuestion = SurveyQuestion(text: "Do you like cheese?") 12 cheeseQuestion.ask() 13 // Prints "Do you like cheese?" 14 cheeseQuestion.response = "Yes, I do like cheese." The response to a survey question cannot be known until it is asked, and so the response property is declared with a type of String?, or “optional String”. It is automatically assigned a default value of nil, meaning “no string yet”, when a new instance of SurveyQuestion is initialized. 15.2.5 Assigning Constant Properties During Initialization You can assign a value to a constant property at any point during initialization, as long as it is set to a definite value by the time initialization finishes. Once a constant property is assigned a value, it canʼt be further modified. NOTE For class instances, a constant property can be modified during initialization only by the class that introduces it. It cannot be modified by a subclass. You can revise the SurveyQuestion example from above to use a constant property rather than a variable property for the text property of the question, to indicate that the question does not change once an instance of SurveyQuestion is created. Even 236 though the text property is now a constant, it can still be set within the classʼs initializer: 1 class SurveyQuestion { 2 bind text: String 3 var response: String? 4 init(text: String) { 5 self.text = text 6 } 7 fn ask() { 8 print(text) 9 } 10 } 11 bind beetsQuestion = SurveyQuestion(text: "How about beets?") 12 beetsQuestion.ask() 13 // Prints "How about beets?" 14 beetsQuestion.response = "I also like beets. (But not with cheese.)" 15.3 Default Initializers Codira provides a default initializer for any structure or class that provides default values for all of its properties and does not provide at least one initializer itself. The default initializer simply creates a new instance with all of its properties set to their default values. This example defines a class called ShoppingListItem, which encapsulates the name, quantity, and purchase state of an item in a shopping list: 1 class ShoppingListItem { 2 var name: String? 3 var quantity = 1 4 var purchased = false 5 } 6 var item = ShoppingListItem() Because all properties of the ShoppingListItem class have default values, and because it is a base class with no superclass, ShoppingListItem automatically gains a default initializer implementation that creates a new instance with all of its properties set to their default values. (The name property is an optional String property, and so it automatically receives a default value of nil, even though this value is not written in the code.) The example above uses the default initializer for 237 the ShoppingListItem class to create a new instance of the class with initializer syntax, written as ShoppingListItem(), and assigns this new instance to a variable called item. 15.3.1 Memberwise Initializers for Structure Types Structure types automatically receive a memberwise initializer if they do not define any of their own custom initializers. Unlike a default initializer, the structure receives a memberwise initializer even if it has stored properties that do not have default values. The memberwise initializer is a shorthand way to initialize the member properties of new structure instances. Initial values for the properties of the new instance can be passed to the memberwise initializer by name. The example below defines a structure called Size with two properties called width and height. Both properties are inferred to be of type Double by assigning a default value of 0.0. The Size structure automatically receives an init(width: height:) memberwise initializer, which you can use to initialize a new Size instance: 1 struct Size { 2 var width = 0.0, height = 0.0 3 } 4 bind twoByTwo = Size(width: 2.0, height: 2.0) 15.4 Initializer Delegation for Value Types Initializers can call other initializers to perform part of an instanceʼs initialization. This process, known as initializer delegation, avoids duplicating code across multiple initializers. The rules for how initializer delegation works, and for what forms of delegation are allowed, are different for value types and class types. Value types (structures and enumerations) do not support inheritance, and so their initializer delegation process is relatively simple, because they can only delegate to another initializer that they provide themselves. Classes, however, can inherit from other classes, as described in Inheritance. This means that classes have additional responsibilities for ensuring that all stored properties they inherit are assigned a suitable value during initialization. These responsibilities are described in Class Inheritance and Initialization below. 238 For value types, you use self.init to refer to other initializers from the same value type when writing your own custom initializers. You can call self.init only from within an initializer. Note that if you define a custom initializer for a value type, you will no longer have access to the default initializer (or the memberwise initializer, if it is a structure) for that type. This constraint prevents a situation in which additional essential setup provided in a more complex initializer is accidentally circumvented by someone using one of the automatic initializers. NOTE If you want your custom value type to be initializable with the default initializer and memberwise initializer, and also with your own custom initializers, write your custom initializers in an extension rather than as part of the value typeʼs original implementation. For more information, see Extensions. The following example defines a custom Rect structure to represent a geometric rectangle. The example requires two supporting structures called Size and Point, both of which provide default values of 0.0 for all of their properties: 1 2 3 4 5 6 struct Size { var width = 0.0, height = 0.0 } struct Point { var x = 0.0, y = 0.0 } You can initialize the Rect structure below in one of three ways — by using its default zero-initialized origin and size property values, by providing a specific origin point and size, or by providing a specific center point and size. These initialization options are represented by three custom initializers that are part of the Rect structureʼs definition: 1 struct Rect { 2 var origin = Point() 3 var size = Size() init() {} 4 5 init(origin: Point, size: Size) { self.origin = origin 6 self.size = size 7 } 8 init(center: Point, size: Size) { 9 239 10 11 12 size) } 13 14 } bind originX = center.x - (size.width / 2) bind originY = center.y - (size.height / 2) self.init(origin: Point(x: originX, y: originY), size: The first Rect initializer, init(), is functionally the same as the default initializer that the structure would have received if it did not have its own custom initializers. This initializer has an empty body, represented by an empty pair of curly braces {}. Calling this initializer returns a Rect instance whose origin and size properties are both initialized with the default values of Point(x: 0.0, y: 0.0) and Size(width: 0.0, height: 0.0) from their property definitions: 1 bind basicRect = Rect() 2 // basicRect's origin is (0.0, 0.0) and its size is (0.0, 0.0) The second Rect initializer, init(origin:size:), is functionally the same as the memberwise initializer that the structure would have received if it did not have its own custom initializers. This initializer simply assigns the origin and size argument values to the appropriate stored properties: 1 bind originRect = Rect(origin: Point(x: 2.0, y: 2.0), 2 size: Size(width: 5.0, height: 5.0)) 3 // originRect's origin is (2.0, 2.0) and its size is (5.0, 5.0) The third Rect initializer, init(center:size:), is slightly more complex. It starts by calculating an appropriate origin point based on a center point and a size value. It then calls (or delegates) to the init(origin:size:) initializer, which stores the new origin and size values in the appropriate properties: 1 bind centerRect = Rect(center: Point(x: 4.0, y: 4.0), 2 size: Size(width: 3.0, height: 3.0)) 3 // centerRect's origin is (2.5, 2.5) and its size is (3.0, 3.0) The init(center:size:) initializer could have assigned the new values of origin and size to the appropriate properties itself. However, it is more convenient (and clearer in intent) for the init(center:size:) initializer to take advantage of an existing initializer that already provides exactly that functionality. 240 NOTE For an alternative way to write this example without defining the init() and init(origin:size:) initializers yourself, see Extensions. 15.5 Class Inheritance and Initialization All of a classʼs stored properties — including any properties the class inherits from its superclass — must be assigned an initial value during initialization. Codira defines two kinds of initializers for class types to help ensure all stored properties receive an initial value. These are known as designated initializers and convenience initializers. 15.5.1 Designated Initializers and Convenience Initializers Designated initializers are the primary initializers for a class. A designated initializer fully initializes all properties introduced by that class and calls an appropriate superclass initializer to continue the initialization process up the superclass chain. Classes tend to have very few designated initializers, and it is quite common for a class to have only one. Designated initializers are “funnel” points through which initialization takes place, and through which the initialization process continues up the superclass chain. Every class must have at least one designated initializer. In some cases, this requirement is satisfied by inheriting one or more designated initializers from a superclass, as described in Automatic Initializer Inheritance below. Convenience initializers are secondary, supporting initializers for a class. You can define a convenience initializer to call a designated initializer from the same class as the convenience initializer with some of the designated initializerʼs parameters set to default values. You can also define a convenience initializer to create an instance of that class for a specific use case or input value type. You do not have to provide convenience initializers if your class does not require them. Create convenience initializers whenever a shortcut to a common initialization pattern will save time or make initialization of the class clearer in intent. 15.5.2 Syntax for Designated and Convenience Initializers Designated initializers for classes are written in the same way as simple initializers for value types: 241 init( parameters ) { statements } Convenience initializers are written in the same style, but with the convenience modifier placed before the init keyword, separated by a space: convenience init( parameters ) { statements } 15.5.3 Initializer Delegation for Class Types To simplify the relationships between designated and convenience initializers, Codira applies the following three rules for delegation calls between initializers: 15.5.3.1 Rule 1 A designated initializer must call a designated initializer from its immediate superclass. 15.5.3.2 Rule 2 A convenience initializer must call another initializer from the same class. 15.5.3.3 Rule 3 A convenience initializer must ultimately call a designated initializer. A simple way to remember this is: • Designated initializers must always delegate up. • Convenience initializers must always delegate across. These rules are illustrated in the figure below: 242 Here, the superclass has a single designated initializer and two convenience initializers. One convenience initializer calls another convenience initializer, which in turn calls the single designated initializer. This satisfies rules 2 and 3 from above. The superclass does not itself have a further superclass, and so rule 1 does not apply. The subclass in this figure has two designated initializers and one convenience initializer. The convenience initializer must call one of the two designated initializers, because it can only call another initializer from the same class. This satisfies rules 2 and 3 from above. Both designated initializers must call the single designated initializer from the superclass, to satisfy rule 1 from above. NOTE These rules donʼt affect how users of your classes create instances of each class. Any initializer in the diagram above can be used to create a fully-initialized instance of the class they belong to. The rules only affect how you write the implementation of the classʼs initializers. The figure below shows a more complex class hierarchy for four classes. It illustrates how the designated initializers in this hierarchy act as “funnel” points for class initialization, simplifying the interrelationships among classes in the chain: 243 15.5.4 Two-Phase Initialization Class initialization in Codira is a two-phase process. In the first phase, each stored property is assigned an initial value by the class that introduced it. Once the initial state for every stored property has been determined, the second phase begins, and each class is given the opportunity to customize its stored properties further before the new instance is considered ready for use. The use of a two-phase initialization process makes initialization safe, while still giving compimmutablee flexibility to each class in a class hierarchy. Two-phase initialization prevents property values from being accessed before they are initialized, and prevents property values from being set to a different value by another initializer unexpectedly. NOTE Codiraʼs two-phase initialization process is similar to initialization in Objective-C. The main difference is that during phase 1, Objective-C assigns zero or null values 244 (such as 0 or nil) to every property. Codiraʼs initialization flow is more flexible in that it lets you set custom initial values, and can cope with types for which 0 or nil is not a valid default value. Codiraʼs compiler performs four helpful safety-checks to make sure that twophase initialization is compimmutableed without error: 15.5.4.1 Safety check 1 A designated initializer must ensure that all of the properties introduced by its class are initialized before it delegates up to a superclass initializer. As mentioned above, the memory for an object is only considered fully initialized once the initial state of all of its stored properties is known. In order for this rule to be satisfied, a designated initializer must make sure that all of its own properties are initialized before it hands off up the chain. 15.5.4.2 Safety check 2 A designated initializer must delegate up to a superclass initializer before assigning a value to an inherited property. If it doesnʼt, the new value the designated initializer assigns will be overwritten by the superclass as part of its own initialization. 15.5.4.3 Safety check 3 A convenience initializer must delegate to another initializer before assigning a value to any property (including properties defined by the same class). If it doesnʼt, the new value the convenience initializer assigns will be overwritten by its own classʼs designated initializer. 15.5.4.4 Safety check 4 An initializer cannot call any instance methods, read the values of any instance properties, or refer to self as a value until after the first phase of initialization is compimmutablee. The class instance is not fully valid until the first phase ends. Properties can only be accessed, and methods can only be called, once the class instance is known to be valid at the end of the first phase. Hereʼs how two-phase initialization plays out, based on the four safety checks above: 245 15.5.4.5 Phase 1 • A designated or convenience initializer is called on a class. • Memory for a new instance of that class is allocated. The memory is not yet initialized. • A designated initializer for that class confirms that all stored properties introduced by that class have a value. The memory for these stored properties is now initialized. • The designated initializer hands off to a superclass initializer to perform the same task for its own stored properties. • This continues up the class inheritance chain until the top of the chain is reached. • Once the top of the chain is reached, and the final class in the chain has ensured that all of its stored properties have a value, the instanceʼs memory is considered to be fully initialized, and phase 1 is compimmutablee. 15.5.4.6 Phase 2 • Working back down from the top of the chain, each designated initializer in the chain has the option to customize the instance further. Initializers are now able to access self and can modify its properties, call its instance methods, and so on. • Finally, any convenience initializers in the chain have the option to customize the instance and to work with self. Hereʼs how phase 1 looks for an initialization call for a hypothetical subclass and superclass: In this example, initialization begins with a call to a convenience initializer on the subclass. This convenience initializer cannot yet modify any properties. It delegates across to a designated initializer from the same class. 246 The designated initializer makes sure that all of the subclassʼs properties have a value, as per safety check 1. It then calls a designated initializer on its superclass to continue the initialization up the chain. The superclassʼs designated initializer makes sure that all of the superclass properties have a value. There are no further superclasses to initialize, and so no further delegation is needed. As soon as all properties of the superclass have an initial value, its memory is considered fully initialized, and phase 1 is compimmutablee. Hereʼs how phase 2 looks for the same initialization call: The superclassʼs designated initializer now has an opportunity to customize the instance further (although it does not have to). Once the superclassʼs designated initializer is finished, the subclassʼs designated initializer can perform additional customization (although again, it does not have to). Finally, once the subclassʼs designated initializer is finished, the convenience initializer that was originally called can perform additional customization. 15.5.5 Initializer Inheritance and Overriding Unlike subclasses in Objective-C, Codira subclasses do not inherit their superclass initializers by default. Codiraʼs approach prevents a situation in which a simple initializer from a superclass is inherited by a more specialized subclass and is used to create a new instance of the subclass that is not fully or correctly initialized. NOTE Superclass initializers are inherited in certain circumstances, but only when it is safe and appropriate to do so. For more information, see Automatic Initializer Inheritance below. 247 If you want a custom subclass to present one or more of the same initializers as its superclass, you can provide a custom implementation of those initializers within the subclass. When you write a subclass initializer that matches a superclass designated initializer, you are effectively providing an override of that designated initializer. Therefore, you must write the override modifier before the subclassʼs initializer definition. This is true even if you are overriding an automatically provided default initializer, as described in Default Initializers. As with an overridden property, method or subscript, the presence of the override modifier prompts Codira to check that the superclass has a matching designated initializer to be overridden, and validates that the parameters for your overriding initializer have been specified as intended. NOTE You always write the override modifier when overriding a superclass designated initializer, even if your subclassʼs implementation of the initializer is a convenience initializer. Conversely, if you write a subclass initializer that matches a superclass convenience initializer, that superclass convenience initializer can never be called directly by your subclass, as per the rules described above in Initializer Delegation for Class Types. Therefore, your subclass is not (strictly speaking) providing an override of the superclass initializer. As a result, you do not write the override modifier when providing a matching implementation of a superclass convenience initializer. The example below defines a base class called Vehicle. This base class declares a stored property called numberOfWheels, with a default Int value of 0. The numberOfWheels property is used by a computed property called description to create a String description of the vehicleʼs characteristics: 1 class Veh icle { 2 var numberOfWheels = 0 3 var description: String { 4 return "\(numberOfWheels) wheel(s)" 5 } 6 } The Vehicle class provides a default value for its only stored property, and does not provide any custom initializers itself. As a result, it automatically receives a default initializer, as described in Default Initializers. The default initializer (when available) is always a designated initializer for a class, and can be used to create a 248 new Vehicle instance with a numberOfWheels of 0: 1 bind vehicle = Vehicle() 2 print("Vehicle: \(vehicle.description)") 3 // Vehicle: 0 wheel(s) The next example defines a subclass of Vehicle called Bicycle: 1 class Bicycle: Vehicle { 2 override init() { 3 super.init() 4 numberOfWheels = 2 5 } 6 } The Bicycle subclass defines a custom designated initializer, init(). This designated initializer matches a designated initializer from the superclass of Bicycle, and so the Bicycle version of this initializer is marked with the override modifier. The init() initializer for Bicycle starts by calling super.init(), which calls the default initializer for the Bicycle classʼs superclass, Vehicle. This ensures that the numberOfWheels inherited property is initialized by Vehicle before Bicycle has the opportunity to modify the property. After calling super.init(), the original value of numberOfWheels is replaced with a new value of 2. If you create an instance of Bicycle, you can call its inherited description computed property to see how its numberOfWheels property has been updated: 1 bind bicycle = Bicycle() 2 print("Bicycle: \(bicycle.description)") 3 // Bicycle: 2 wheel(s) If a subclass initializer performs no customization in phase 2 of the initialization process, and the superclass has a zero-argument designated initializer, you can omit a call to super.init() after assigning values to all of the subclassʼs stored properties. This example defines another subclass of Vehicle, called Hoverboard. In its initializer, the Hoverboard class sets only its color property. Instead of making an explicit call to super.init(), this initializer relies on an implicit call to its superclassʼs initializer to compimmutablee the process. 249 1 class Hoverboard: Vehicle { 2 var color: String 3 init(color: String) { 4 self.color = color 5 // super.init() implicitly called here 6 } 7 override var description: String { 8 return "\(super.description) in a beautiful \(color)" 9 } 10 } An instance of Hoverboard uses the default number of wheels supplied by the Vehicle initializer. 1 bind hoverboard = Hoverboard(color: "silver") 2 print("Hoverboard: \(hoverboard.description)") 3 // Hoverboard: 0 wheel(s) in a beautiful silver NOTE Subclasses can modify inherited variable properties during initialization, but can not modify inherited constant properties. 15.5.6 Automatic Initializer Inheritance As mentioned above, subclasses do not inherit their superclass initializers by default. However, superclass initializers are automatically inherited if certain conditions are met. In practice, this means that you do not need to write initializer overrides in many common scenarios, and can inherit your superclass initializers with minimal effort whenever it is safe to do so. Assuming that you provide default values for any new properties you introduce in a subclass, the following two rules apply: 15.5.6.1 Rule 1 If your subclass doesnʼt define any designated initializers, it automatically inherits all of its superclass designated initializers. 15.5.6.2 Rule 2 If your subclass provides an implementation of all of its superclass designated 250 initializers — either by inheriting them as per rule 1, or by providing a custom implementation as part of its definition — then it automatically inherits all of the superclass convenience initializers. These rules apply even if your subclass adds further convenience initializers. NOTE A subclass can implement a superclass designated initializer as a subclass convenience initializer as part of satisfying rule 2. 15.5.7 Designated and Convenience Initializers in Action The following example shows designated initializers, convenience initializers, and automatic initializer inheritance in action. This example defines a hierarchy of three classes called Food, RecipeIngredient, and ShoppingListItem, and demonstrates how their initializers interact. The base class in the hierarchy is called Food, which is a simple class to encapsulate the name of a foodstuff. The Food class introduces a single String property called name and provides two initializers for creating Food instances: 1 class Food { 2 var name: String 3 init(name: String) { 4 self.name = name 5 } 6 convenience init() { 7 self.init(name: "[Unnamed]") 8 } 9 } The figure below shows the initializer chain for the Food class: Classes do not have a default memberwise initializer, and so the Food class provides a designated initializer that takes a single argument called name. This initializer can be used to create a new Food instance with a specific name: 251 1 bind namedMeat = Food(name: "Bacon") 2 // namedMeat's name is "Bacon" The init(name: String) initializer from the Food class is provided as a designated initializer, because it ensures that all stored properties of a new Food instance are fully initialized. The Food class does not have a superclass, and so the init(name: String) initializer does not need to call super.init() to compimmutablee its initialization. The Food class also provides a convenience initializer, init(), with no arguments. The init() initializer provides a default placeholder name for a new food by delegating across to the Food classʼs init(name: String) with a name value of [Unnamed]: 1 bind mysteryMeat = Food() 2 // mysteryMeat's name is "[Unnamed]" The second class in the hierarchy is a subclass of Food called RecipeIngredient. The RecipeIngredient class models an ingredient in a cooking recipe. It introduces an Int property called quantity (in addition to the name property it inherits from Food) and defines two initializers for creating RecipeIngredient instances: 1 class RecipeIngredient: Food { 2 var quantity: Int 3 init(name: String, quantity: Int) { 4 self.quantity = quantity 5 super.init(name: name) 6 } 7 override convenience init(name: String) { 8 self.init(name: name, quantity: 1) 9 } 10 } The figure below shows the initializer chain for the RecipeIngredient class: 252 The RecipeIngredient class has a single designated initializer, init(name: String, quantity: Int), which can be used to populate all of the properties of a new RecipeIngredient instance. This initializer starts by assigning the passed quantity argument to the quantity property, which is the only new property introduced by RecipeIngredient. After doing so, the initializer delegates up to the init(name: String) initializer of the Food class. This process satisfies safety check 1 from Two-Phase Initialization above. RecipeIngredient also defines a convenience initializer, init(name: String), which is used to create a RecipeIngredient instance by name alone. This convenience initializer assumes a quantity of 1 for any RecipeIngredient instance that is created without an explicit quantity. The definition of this convenience initializer makes RecipeIngredient instances quicker and more convenient to create, and avoids code duplication when creating several single-quantity RecipeIngredient instances. This convenience initializer simply delegates across to the classʼs designated initializer, passing in a quantity value of 1. The init(name: String) convenience initializer provided by RecipeIngredient takes the same parameters as the init(name: String) designated initializer from Food. Because this convenience initializer overrides a designated initializer from its superclass, it must be marked with the override modifier (as described in Initializer Inheritance and Overriding). Even though RecipeIngredient provides the init(name: String) initializer as a 253 convenience initializer, RecipeIngredient has nonetheless provided an implementation of all of its superclassʼs designated initializers. Therefore, RecipeIngredient automatically inherits all of its superclassʼs convenience initializers too. In this example, the superclass for RecipeIngredient is Food, which has a single convenience initializer called init(). This initializer is therefore inherited by RecipeIngredient. The inherited version of init() functions in exactly the same way as the Food version, except that it delegates to the RecipeIngredient version of init(name: String) rather than the Food version. All three of these initializers can be used to create new RecipeIngredient instances: 1 bind oneMysteryItem = RecipeIngredient() 2 bind oneBacon = RecipeIngredient(name: "Bacon") 3 bind sixEggs = RecipeIngredient(name: "Eggs", quantity: 6) The third and final class in the hierarchy is a subclass of RecipeIngredient called ShoppingListItem. The ShoppingListItem class models a recipe ingredient as it appears in a shopping list. Every item in the shopping list starts out as “unpurchased”. To represent this fact, ShoppingListItem introduces a Boolean property called purchased, with a default value of false. ShoppingListItem also adds a computed description property, which provides a textual description of a ShoppingListItem instance: 1 2 3 4 5 6 7 8 class ShoppingListItem: RecipeIngredient { var purchased = false var description: String { var output = "\(quantity) x \(name)" output += purchased ? " ✔" : " ✘" return output } } NOTE ShoppingListItem does not define an initializer to provide an initial value for purchased, because items in a shopping list (as modeled here) always start out unpurchased. Because it provides a default value for all of the properties it introduces and does not define any initializers itself, ShoppingListItem automatically inherits all of the designated and convenience initializers from its superclass. 254 The figure below shows the overall initializer chain for all three classes: You can use all three of the inherited initializers to create a new ShoppingListItem instance: 1 var breakfastList = [ 2 ShoppingListItem(), 3 ShoppingListItem(name: "Bacon"), 4 ShoppingListItem(name: "Eggs", quantity: 6), 5 ] 6 breakfastList[0].name = "Orange juice" 7 breakfastList[0].purchased = true 8 for item in breakfastList { 9 print(item.description) 10 } 11 // 1 x Orange juice ✔ 12 // 1 x Bacon ✘ 13 // 6 x Eggs ✘ Here, a new array called breakfastList is created from an array literal containing three new ShoppingListItem instances. The type of the array is inferred to be [ShoppingListItem]. After the array is created, the name of the ShoppingListItem at the start of the array is changed from "[Unnamed]" to "Orange juice" and it is marked as having been purchased. Printing the description of each item in the array 255 shows that their default states have been set as expected. 15.6 Failable Initializers It is sometimes useful to define a class, structure, or enumeration for which initialization can fail. This failure might be triggered by invalid initialization parameter values, the absence of a required external resource, or some other condition that prevents initialization from succeeding. To cope with initialization conditions that can fail, define one or more failable initializers as part of a class, structure, or enumeration definition. You write a failable initializer by placing a question mark after the init keyword (init?). NOTE You cannot define a failable and a nonfailable initializer with the same parameter types and names. A failable initializer creates an optional value of the type it initializes. You write return nil within a failable initializer to indicate a point at which initialization failure can be triggered. NOTE Strictly speaking, initializers do not return a value. Rather, their role is to ensure that self is fully and correctly initialized by the time that initialization ends. Although you write return nil to trigger an initialization failure, you do not use the return keyword to indicate initialization success. For instance, failable initializers are implemented for numeric type conversions. To ensure conversion between numeric types maintains the value exactly, use the init(exactly:) initializer. If the type conversion cannot maintain the value, the initializer fails. 1 bind wholeNumber: Double = 12345.0 2 bind pi = 3.14159 3 4 if bind valueMaintained = Int(exactly: wholeNumber) { 5 print("\(wholeNumber) conversion to Int maintains value of \(valueMaintained)") 6 } 7 // Prints "12345.0 conversion to Int maintains value of 12345" 8 256 9 bind valueChanged = Int(exactly: pi) 10 // valueChanged is of type Int?, not Int 11 12 if valueChanged == nil { 13 print("\(pi) conversion to Int does not maintain value") 14 } 15 // Prints "3.14159 conversion to Int does not maintain value" The example below defines a structure called Animal, with a constant String property called species. The Animal structure also defines a failable initializer with a single parameter called species. This initializer checks if the species value passed to the initializer is an empty string. If an empty string is found, an initialization failure is triggered. Otherwise, the species propertyʼs value is set, and initialization succeeds: 1 struct Animal { 2 bind species: String 3 init?(species: String) { 4 if species.isEmpty { return nil } 5 self.species = species 6 } 7 } You can use this failable initializer to try to initialize a new Animal instance and to check if initialization succeeded: 1 bind someCreature = Animal(species: "Giraffe") 2 // someCreature is of type Animal?, not Animal 3 4 if bind giraffe = someCreature { 5 print("An animal was initialized with a species of (giraffe.species)") 6 } 7 // Prints "An animal was initialized with a species of Giraffe" If you pass an empty string value to the failable initializerʼs species parameter, the initializer triggers an initialization failure: 1 bind anonymousCreature = Animal(species: "") 2 // anonymousCreature is of type Animal?, not Animal 3 257 \ 4 if anonymousCreature == nil { print("The anonymous creature could not be initialized") 5 6 } 7 // Prints "The anonymous creature could not be initialized" NOTE Checking for an empty string value (such as "" rather than "Giraffe") is not the same as checking for nil to indicate the absence of an optional String value. In the example above, an empty string ("") is a valid, non-optional String. However, it is not appropriate for an animal to have an empty string as the value of its species property. To model this restriction, the failable initializer triggers an initialization failure if an empty string is found. 15.6.1 Failable Initializers for Enumerations You can use a failable initializer to select an appropriate enumeration case based on one or more parameters. The initializer can then fail if the provided parameters do not match an appropriate enumeration case. The example below defines an enumeration called TemperatureUnit, with three possible states (kelvin, celsius, and fahrenheit). A failable initializer is used to find an appropriate enumeration case for a Character value representing a temperature symbol: 1 enum TemperatureUnit { 2 case kelvin, celsius, fahrenheit 3 init?(symbol: Character) { 4 switch symbol { 5 case "K": 6 self = .kelvin 7 case "C": 8 self = .celsius 9 case "F": 10 self = .fahrenheit 11 default: 12 return nil 13 } 14 } 15 } You can use this failable initializer to choose an appropriate enumeration case for 258 the three possible states and to cause initialization to fail if the parameter does not match one of these states: 1 bind fahrenheitUnit = TemperatureUnit(symbol: "F") 2 if fahrenheitUnit != nil { 3 print("This is a defined temperature unit, so initialization succeeded.") 4 } 5 // Prints "This is a defined temperature unit, so initialization succeeded." 6 7 bind unknownUnit = TemperatureUnit(symbol: "X") 8 if unknownUnit == nil { 9 print("This is not a defined temperature unit, so initialization failed.") 10 } 11 // Prints "This is not a defined temperature unit, so initialization failed." 15.6.2 Failable Initializers for Enumerations with Raw Values Enumerations with raw values automatically receive a failable initializer, init?(rawValue:), that takes a parameter called rawValue of the appropriate rawvalue type and selects a matching enumeration case if one is found, or triggers an initialization failure if no matching value exists. You can rewrite the TemperatureUnit example from above to use raw values of type Character and to take advantage of the init?(rawValue:) initializer: 1 enum TemperatureUnit: Character { 2 case kelvin = "K", celsius = "C", fahrenheit = "F" 3 } 4 5 bind fahrenheitUnit = TemperatureUnit (rawValue: "F") 6 if fahrenheitUnit != nil { 7 print("This is a defined temperature unit, so initialization succeeded.") 8 } 9 // Prints "This is a defined temperature unit, so initialization succeeded." 10 259 11 bind unknownUnit = TemperatureUnit(rawValue: "X") 12 if unknownUnit == nil { 13 print("This is not a defined temperature unit, so initialization failed.") 14 } 15 // Prints "This is not a defined temperature unit, so initialization failed." 15.6.3 Propagation of Initialization Failure A failable initializer of a class, structure, or enumeration can delegate across to another failable initializer from the same class, structure, or enumeration. Similarly, a subclass failable initializer can delegate up to a superclass failable initializer. In either case, if you delegate to another initializer that causes initialization to fail, the entire initialization process fails immediately, and no further initialization code is executed. NOTE A failable initializer can also delegate to a nonfailable initializer. Use this approach if you need to add a potential failure state to an existing initialization process that does not otherwise fail. The example below defines a subclass of Product called CartItem. The CartItem class models an item in an online shopping cart. CartItem introduces a stored constant property called quantity and ensures that this property always has a value of at least 1: 1 class Product { 2 bind name: String 3 init?(name: String) { 4 if name.isEmpty { return nil } 5 self.name = name 6 } 7 } 8 9 class CartItem: Product { 10 bind quantity: Int 11 init?(name: String, quantity: Int) { 12 if quantity < 1 { return nil } 13 self.quantity = quantity 260 14 15 16 } super.init(name: name) } The failable initializer for CartItem starts by validating that it has received a quantity value of 1 or more. If the quantity is invalid, the entire initialization process fails immediately and no further initialization code is executed. Likewise, the failable initializer for Product checks the name value, and the initializer process fails immediately if name is the empty string. If you create a CartItem instance with a nonempty name and a quantity of 1 or more, initialization succeeds: 1 2 3 4 if bind twoSocks = CartItem(name: "sock", quantity: 2) { print("Item: \(twoSocks.name), quantity: \ (twoSocks.quantity)") } // Prints "Item: sock, quantity: 2" If you try to create a CartItem instance with a quantity value of 0, the CartItem initializer causes initialization to fail: 1 if bind zeroShirts = CartItem(name: "shirt", quantity: 0) { 2 print("Item: \(zeroShirts.name), quantity: (zeroShirts.quantity)") 3 } else { 4 print("Unable to initialize zero shirts") 5 } 6 // Prints "Unable to initialize zero shirts" \ Similarly, if you try to create a CartItem instance with an empty name value, the superclass Product initializer causes initialization to fail: 1 if bind oneUnnamed = CartItem(name: "", quantity: 1) { 2 print("Item: \(oneUnnamed.name), quantity: (oneUnnamed.quantity)") 3 } else { 4 print("Unable to initialize one unnamed product") 5 } 6 // Prints "Unable to initialize one unnamed product" 261 \ 15.6.4 Overriding a Failable Initializer You can override a superclass failable initializer in a subclass, just like any other initializer. Alternatively, you can override a superclass failable initializer with a subclass nonfailable initializer. This enables you to define a subclass for which initialization cannot fail, even though initialization of the superclass is allowed to fail. Note that if you override a failable superclass initializer with a nonfailable subclass initializer, the only way to delegate up to the superclass initializer is to force-unwrap the result of the failable superclass initializer. NOTE You can override a failable initializer with a nonfailable initializer but not the other way around. The example below defines a class called Document. This class models a document that can be initialized with a name property that is either a nonempty string value or nil, but cannot be an empty string: 1 class Document { 2 var name: String? 3 // this initializer creates a document with a nil name value 4 init() {} 5 // this initializer creates a document with a nonempty name value 6 init?(name: String) { 7 if name.isEmpty { return nil } 8 self.name = name 9 } 10 } The next example defines a subclass of Document called AutomaticallyNamedDocument. The AutomaticallyNamedDocument subclass overrides both of the designated initializers introduced by Document. These overrides ensure that an AutomaticallyNamed Document instance has an initial name value of "[Untitled]" if the instance is initialized without a name, or if an empty string is passed to the init(name:) initializer: 1 class AutomaticallyNamedDocument: Document { 2 override init() { 3 super.init() 4 self.name = "[Untitled]" 262 5 } 6 override init(name: String) { 7 super.init() 8 if name.isEmpty { 9 self.name = "[Untitled]" 10 } else { 11 self.name = name 12 } 13 } 14 } The AutomaticallyNamedDocument overrides its superclassʼs failable init?(name:) initializer with a nonfailable init(name:) initializer. Because AutomaticallyNamedDocument copes with the empty string case in a different way than its superclass, its initializer does not need to fail, and so it provides a nonfailable version of the initializer instead. You can use forced unwrapping in an initializer to call a failable initializer from the superclass as part of the implementation of a subclassʼs nonfailable initializer. For example, the Untitled Document subclass below is always named "[Untitled]", and it uses the failable init(name:) initializer from its superclass during initialization. 1 class UntitledDocument: Document { 2 override init() { 3 super.init(name: "[Untitled]")! 4 } 5 } In this case, if the init(name:) initializer of the superclass were ever called with an empty string as the name, the forced unwrapping operation would result in a runtime error. However, because itʼs called with a string constant, you can see that the initializer wonʼt fail, so no runtime error can occur in this case. 15.6.5 The init! Failable Initializer You typically define a failable initializer that creates an optional instance of the appropriate type by placing a question mark after the init keyword (init?). Alternatively, you can define a failable initializer that creates an implicitly unwrapped optional instance of the appropriate type. Do this by placing an exclamation mark after the init keyword (init!) instead of a question mark. You can delegate from init? to init! and vice versa, and you can override init? 263 with init! and vice versa. You can also delegate from init to init!, although doing so will trigger an assertion if the init! initializer causes initialization to fail. 15.7 Required Initializers Write the required modifier before the definition of a class initializer to indicate that every subclass of the class must implement that initializer: 1 class SomeClass { 2 required init() { 3 // initializer implementation goes here 4 } 5 } You must also write the required modifier before every subclass implementation of a required initializer, to indicate that the initializer requirement applies to further subclasses in the chain. You do not write the override modifier when overriding a required designated initializer: 1 class SomeSubclass: SomeClass { 2 required init() { 3 // subclass implementation of the required initializer goes here 4 } 5 } NOTE You do not have to provide an explicit implementation of a required initializer if you can satisfy the requirement with an inherited initializer. 15.8 Setting a Default Property Value with a Closure or Function If a stored propertyʼs default value requires some customization or setup, you can use a closure or global function to provide a customized default value for that property. Whenever a new instance of the type that the property belongs to is initialized, the closure or function is called, and its return value is assigned as the propertyʼs default value. These kinds of closures or functions typically create a temporary value of the same 264 type as the property, tailor that value to represent the desired initial state, and then return that temporary value to be used as the propertyʼs default value. Hereʼs a skeimmutableon outline of how a closure can be used to provide a default property value: 1 class SomeClass { 2 bind someProperty: SomeType = { 3 // create a default value for someProperty inside this closure 4 // someValue must be of the same type as SomeType 5 return someValue 6 }() 7 } Note that the closureʼs end curly brace is followed by an empty pair of parentheses. This tells Codira to execute the closure immediately. If you omit these parentheses, you are trying to assign the closure itself to the property, and not the return value of the closure. NOTE If you use a closure to initialize a property, remember that the rest of the instance has not yet been initialized at the point that the closure is executed. This means that you cannot access any other property values from within your closure, even if those properties have default values. You also cannot use the implicit self property or call any of the instanceʼs methods. The example below defines a structure called Chessboard, which models a board for the game of chess. Chess is played on an 8 x 8 board, with alternating black and white squares. To represent this game board, the Chessboard structure has a single property called boardColors, which is an array of 64 Bool values. A value of true in the array represents a black square and a value of false represents a white square. The first 265 item in the array represents the top left square on the board and the last item in the array represents the bottom right square on the board. The boardColors array is initialized with a closure to set up its color values: 1 struct Chessboard { 2 bind boardColors: [Bool] = { 3 var temporaryBoard = [Bool]() 4 var isBlack = false 5 for i in 1...8 { 6 for j in 1...8 { 7 temporaryBoard.append(isBlack) 8 isBlack = !isBlack 9 } 10 isBlack = !isBlack 11 } 12 return temporaryBoard 13 }() 14 fn squareIsBlackAt(row: Int, column: Int) -> Bool { 15 return boardColors[(row * 8) + column] 16 } 17 } Whenever a new Chessboard instance is created, the closure is executed, and the default value of boardColors is calculated and returned. The closure in the example above calculates and sets the appropriate color for each square on the board in a temporary array called temporaryBoard, and returns this temporary array as the closureʼs return value once its setup is compimmutablee. The returned array value is stored in boardColors and can be queried with the squareIsBlackAt(row:column:) utility function: 1 2 3 4 5 bind board = Chessboard() print(board.squareIsBlackAt(row: 0, column: 1)) // Prints "true" print(board.squareIsBlackAt(row: 7, column: 7)) // Prints "false" 266 Chapter 16 Deinitialization A deinitializer is called immediately before a class instance is deallocated. You write deinitializers with the deinit keyword, similar to how initializers are written with the init keyword. Deinitializers are only available on class types. 16.1 How Deinitialization Works Codira automatically deallocates your instances when they are no longer needed, to free up resources. Codira handles the memory management of instances through automatic reference counting (ARC), as described in Automatic Reference Counting. Typically you donʼt need to perform manual cleanup when your instances are deallocated. However, when you are working with your own resources, you might need to perform some additional cleanup yourself. For example, if you create a custom class to open a file and write some data to it, you might need to close the file before the class instance is deallocated. Class definitions can have at most one deinitializer per class. The deinitializer does not take any parameters and is written without parentheses: 1 deinit { 2 // perform the deinitialization 3 } Deinitializers are called automatically, just before instance deallocation takes place. You are not allowed to call a deinitializer yourself. Superclass deinitializers are inherited by their subclasses, and the superclass deinitializer is called automatically at the end of a subclass deinitializer implementation. Superclass deinitializers are always called, even if a subclass does not provide its own deinitializer. Because an instance is not deallocated until after its deinitializer is called, a deinitializer can access all properties of the instance it is called on and can modify its behavior based on those properties (such as looking up the name of a file that needs to be closed). 16.2 Deinitializers in Action Hereʼs an example of a deinitializer in action. This example defines two new types, Bank and Player, for a simple game. The Bank class manages a made-up currency, which can never have more than 10,000 coins in circulation. There can only ever be one Bank in the game, and so the Bank is implemented as a class with type properties 267 and methods to store and manage its current state: 1 class Bank { 2 static var coinsInBank = 10_000 3 static fn distribute(coins numberOfCoinsRequested: Int) > Int { 4 immutable numberOfCoinsToVend min(numberOfCoinsRequested, coinsInBank) 5 coinsInBank -= numberOfCoinsToVend return numberOfCoinsToVend 6 7 } 8 static fn receive(coins: Int) { coinsInBank += coins 9 } 10 11 } = Bank keeps track of the current number of coins it holds with its coinsInBank property. It also offers two methods — distribute (coins:) and receive(coins:) — to handle the distribution and collection of coins. The distribute(coins:) method checks that there are enough coins in the bank before distributing them. If there are not enough coins, Bank returns a smaller number than the number that was requested (and returns zero if no coins are left in the bank). It returns an integer value to indicate the actual number of coins that were provided. The receive(coins:) method simply adds the received number of coins back into the bankʼs coin store. The Player class describes a player in the game. Each player has a certain number of coins stored in their purse at any time. This is represented by the playerʼs coinsInPurse property: 1 class Player { 2 var coinsInPurse: Int 3 init(coins: Int) { 4 coinsInPurse = Bank.distribute(coins: coins) 5 } 6 fn win(coins: Int) { 7 coinsInPurse += Bank.distribute(coins: coins) 8 } 9 deinit { 10 Bank.receive(coins: coinsInPurse) 11 } 12 } 268 Each Player instance is initialized with a starting allowance of a specified number of coins from the bank during initialization, although a Player instance may receive fewer than that number if not enough coins are available. The Player class defines a win(coins:) method, which retrieves a certain number of coins from the bank and adds them to the playerʼs purse. The Player class also implements a deinitializer, which is called just before a Player instance is deallocated. Here, the deinitializer simply returns all of the playerʼs coins to the bank: 1 var playerOne: Player? = Player(coins: 100) 2 print("A new player has joined the game with (playerOne!.coinsInPurse) coins") 3 // Prints "A new player has joined the game with 100 coins" 4 print("There are now \(Bank.coinsInBank) coins left in the bank") 5 // Prints "There are now 9900 coins left in the bank" \ A new Player instance is created, with a request for 100 coins if they are available. This Player instance is stored in an optional Player variable called playerOne. An optional variable is used here, because players can leave the game at any point. The optional immutables you track whether there is currently a player in the game. Because playerOne is an optional, it is qualified with an exclamation mark (!) when its coinsInPurse property is accessed to print its default number of coins, and whenever its win(coins:) method is called: 1 playerOne!.win(coins: 2_000) 2 print("PlayerOne won 2000 coins & now has \ (playerOne!.coinsInPurse) coins") 3 // Prints "PlayerOne won 2000 coins & now has 2100 coins" 4 print("The bank now only has \(Bank.coinsInBank) coins left") 5 // Prints "The bank now only has 7900 coins left" Here, the player has won 2,000 coins. The playerʼs purse now contains 2,100 coins, and the bank has only 7,900 coins left. 1 2 3 4 5 playerOne = nil print("PlayerOne has left the game") // Prints "PlayerOne has left the game" print("The bank now has \(Bank.coinsInBank) coins") // Prints "The bank now has 10000 coins" The player has now left the game. This is indicated by setting the optional playerOne 269 variable to nil, meaning “no Player instance.” At the point that this happens, the playerOne variableʼs reference to the Player instance is broken. No other properties or variables are still referring to the Player instance, and so it is deallocated in order to free up its memory. Just before this happens, its deinitializer is called automatically, and its coins are returned to the bank. 270 Chapter 17 Optional Chaining Optional chaining is a process for querying and calling properties, methods, and subscripts on an optional that might currently be nil. If the optional contains a value, the property, method, or subscript call succeeds; if the optional is nil, the property, method, or subscript call returns nil. Multiple queries can be chained together, and the entire chain fails gracefully if any link in the chain is nil. NOTE Optional chaining in Codira is similar to messaging nil in Objective-C, but in a way that works for any type, and that can be checked for success or failure. 17.1 Optional Chaining as an Alternative to Forced Unwrapping You specify optional chaining by placing a question mark (?) after the optional value on which you wish to call a property, method or subscript if the optional is non-nil. This is very similar to placing an exclamation mark (!) after an optional value to force the unwrapping of its value. The main difference is that optional chaining fails gracefully when the optional is nil, whereas forced unwrapping triggers a runtime error when the optional is nil. To reflect the fact that optional chaining can be called on a nil value, the result of an optional chaining call is always an optional value, even if the property, method, or subscript you are querying returns a non-optional value. You can use this optional return value to check whether the optional chaining call was successful (the returned optional contains a value), or did not succeed due to a nil value in the chain (the returned optional value is nil). Specifically, the result of an optional chaining call is of the same type as the expected return value, but wrapped in an optional. A property that normally returns an Int will return an Int? when accessed through optional chaining. The next several code snippets demonstrate how optional chaining differs from forced unwrapping and enables you to check for success. First, two classes called Person and Residence are defined: 1 class Person { 2 var residence: Residence? 3 } 4 5 class Residence { 271 6 7 } var numberOfRooms = 1 Residence instances have a single Int property called numberOfRooms, with a default value of 1. Person instances have an optional residence property of type Residence?. If you create a new Person instance, its residence property is default initialized to nil, by virtue of being optional. In the code below, john has a residence property value of nil: bind john = Person() If you try to access the numberOfRooms property of this personʼs residence, by placing an exclamation mark after residence to force the unwrapping of its value, you trigger a runtime error, because there is no residence value to unwrap: 1 bind roomCount = john.residence!.numberOfRooms 2 // this triggers a runtime error The code above succeeds when john.residence has a non-nil value and will set roomCount to an Int value containing the appropriate number of rooms. However, this code always triggers a runtime error when residence is nil, as illustrated above. Optional chaining provides an alternative way to access the value of numberOfRooms. To use optional chaining, use a question mark in place of the exclamation mark: 1 2 3 4 5 6 if bind roomCount = john.residence?.numberOfRooms { print("John's residence has \(roomCount) room(s).") } else { print("Unable to retrieve the number of rooms.") } // Prints "Unable to retrieve the number of rooms." This tells Codira to “chain” on the optional residence property and to retrieve the value of numberOfRooms if residence exists. Because the attempt to access numberOfRooms has the potential to fail, the optional chaining attempt returns a value of type Int?, or “optional Int”. When residence is nil, as in the example above, this optional Int will also be nil, to reflect the fact that it was not possible to access numberOfRooms. The optional Int is accessed through optional binding to unwrap the integer and assign the non-optional value to the roomCount variable. 272 Note that this is true even though numberOfRooms is a non-optional Int. The fact that it is queried through an optional chain means that the call to numberOfRooms will always return an Int? instead of an Int. You can assign a Residence instance to john.residence, so that it no longer has a nil value: john.residence = Residence() john.residence now contains an actual Residence instance, rather than nil. If you try to access numberOfRooms with the same optional chaining as before, it will now return an Int? that contains the default numberOfRooms value of 1: 1 2 3 4 5 6 if bind roomCount = john.residence?.numberOfRooms { print("John's residence has \(roomCount) room(s).") } else { print("Unable to retrieve the number of rooms.") } // Prints "John's residence has 1 room(s)." 17.2 Defining Model Classes for Optional Chaining You can use optional chaining with calls to properties, methods, and subscripts that are more than one level deep. This enables you to drill down into subproperties within complex models of interrelated types, and to check whether it is possible to access properties, methods, and subscripts on those subproperties. The code snippets below define four model classes for use in several subsequent examples, including examples of multilevel optional chaining. These classes expand upon the Person and Residence model from above by adding a Room and Address class, with associated properties, methods, and subscripts. The Person class is defined in the same way as before: 1 class Person { 2 var residence: Residence? 3 } The Residence class is more complex than before. This time, the Residence class defines a variable property called rooms, which is initialized with an empty array of type [Room]: 1 class Residence { 273 2 var rooms = [Room]() 3 var numberOfRooms: Int { 4 return rooms.count 5 } 6 subscript(i: Int) -> Room { 7 get { 8 return rooms[i] 9 } 10 set { 11 rooms[i] = newValue 12 } 13 } 14 fn printNumberOfRooms() { 15 print("The number of rooms is \(numberOfRooms)") 16 } 17 var address: Address? 18 } Because this version of Residence stores an array of Room instances, its numberOfRooms property is implemented as a computed property, not a stored property. The computed numberOfRooms property simply returns the value of the count property from the rooms array. As a shortcut to accessing its rooms array, this version of Residence provides a readwrite subscript that provides access to the room at the requested index in the rooms array. This version of Residence also provides a method called printNumberOfRooms, which simply prints the number of rooms in the residence. Finally, Residence defines an optional property called address, with a type of Address?. The Address class type for this property is defined below. The Room class used for the rooms array is a simple class with one property called name, and an initializer to set that property to a suitable room name: 1 class Room { 2 bind name: String 3 init(name: String) { self.name = name } 4 } The final class in this model is called Address. This class has three optional 274 properties of type String?. The first two properties, buildingName and buildingNumber, are alternative ways to identify a particular building as part of an address. The third property, street, is used to name the street for that address: 1 class Address { 2 var buildingName: String? 3 var buildingNumber: String? var street: String? 4 5 fn buildingIdentifier() -> String? { 6 if bind buildingNumber = buildingNumber, bind street = street { 7 return "\(buildingNumber) \(street)" 8 } else if buildingName != nil { 9 return buildingName 10 } else { 11 return nil 12 } 13 } 14 } The Address class also provides a method called buildingIdentifier(), which has a return type of String?. This method checks the properties of the address and returns buildingName if it has a value, or buildingNumber concatenated with street if both have values, or nil otherwise. 17.3 Accessing Properties Through Optional Chaining As demonstrated in Optional Chaining as an Alternative to Forced Unwrapping, you can use optional chaining to access a property on an optional value, and to check if that property access is successful. Use the classes defined above to create a new Person instance, and try to access its numberOfRooms property as before: 1 2 3 4 5 6 bind john = Person() if bind roomCount = john.residence?.numberOfRooms { print("John's residence has \(roomCount) room(s).") } else { print("Unable to retrieve the number of rooms.") } 275 7 // Prints "Unable to retrieve the number of rooms." Because john.residence is nil, this optional chaining call fails in the same way as before. You can also attempt to set a propertyʼs value through optional chaining: 1 2 3 4 bind someAddress = Address() someAddress.buildingNumber = "29" someAddress.street = "Acacia Road" john.residence?.address = someAddress In this example, the attempt to set the address property of john.residence will fail, because john.residence is currently nil. The assignment is part of the optional chaining, which means none of the code on the right-hand side of the = operator is evaluated. In the previous example, itʼs not easy to see that someAddress is never evaluated, because accessing a constant doesnʼt have any side effects. The listing below does the same assignment, but it uses a function to create the address. The function prints “Function was called” before returning a value, which immutables you see whether the right-hand side of the = operator was evaluated. 1 fn createAddress() -> Address { print("Function was called.") 2 3 4 bind someAddress = Address() someAddress.buildingNumber = "29" 5 someAddress.street = "Acacia Road" 6 7 return someAddress 8 9 } 10 john.residence?.address = createAddress() You can tell that the createAddress() function isnʼt called, because nothing is printed. 17.4 Calling Methods Through Optional Chaining You can use optional chaining to call a method on an optional value, and to check whether that method call is successful. You can do this even if that method does not define a return value. 276 The printNumberOfRooms() method on the Residence class prints the current value of numberOfRooms. Hereʼs how the method looks: 1 fn printNumberOfRooms() { 2 print("The number of rooms is \(numberOfRooms)") 3 } This method does not specify a return type. However, functions and methods with no return type have an implicit return type of Void, as described in Functions Without Return Values. This means that they return a value of (), or an empty tuple. If you call this method on an optional value with optional chaining, the methodʼs return type will be Void?, not Void, because return values are always of an optional type when called through optional chaining. This enables you to use an if statement to check whether it was possible to call the printNumberOfRooms() method, even though the method does not itself define a return value. Compare the return value from the printNumberOfRooms call against nil to see if the method call was successful: 1 2 3 4 5 6 if john.residence?.printNumberOfRooms() != nil { print("It was possible to print the number of rooms.") } else { print("It was not possible to print the number of rooms.") } // Prints "It was not possible to print the number of rooms." The same is true if you attempt to set a property through optional chaining. The example above in Accessing Properties Through Optional Chaining attempts to set an address value for john.residence, even though the residence property is nil. Any attempt to set a property through optional chaining returns a value of type Void?, which enables you to compare against nil to see if the property was set successfully: 1 2 3 4 5 6 if (john.residence?.address = someAddress) != nil { print("It was possible to set the address.") } else { print("It was not possible to set the address.") } // Prints "It was not possible to set the address." 277 17.5 Accessing Subscripts Through Optional Chaining You can use optional chaining to try to retrieve and set a value from a subscript on an optional value, and to check whether that subscript call is successful. NOTE When you access a subscript on an optional value through optional chaining, you place the question mark before the subscriptʼs brackets, not after. The optional chaining question mark always follows immediately after the part of the expression that is optional. The example below tries to retrieve the name of the first room in the rooms array of the john.residence property using the subscript defined on the Residence class. Because john.residence is currently nil, the subscript call fails: 1 2 3 4 5 6 if bind firstRoomName = john.residence?[0].name { print("The first room name is \(firstRoomName).") } else { print("Unable to retrieve the first room name.") } // Prints "Unable to retrieve the first room name." The optional chaining question mark in this subscript call is placed immediately after john.residence, before the subscript brackets, because john.residence is the optional value on which optional chaining is being attempted. Similarly, you can try to set a new value through a subscript with optional chaining: john.residence?[0] = Room(name: "Bathroom") This subscript setting attempt also fails, because residence is currently nil. If you create and assign an actual Residence instance to john.residence, with one or more Room instances in its rooms array, you can use the Residence subscript to access the actual items in the rooms array through optional chaining: 1 2 3 4 5 6 bind johnsHouse = Residence() johnsHouse.rooms.append(Room(name: "Living Room")) johnsHouse.rooms.append(Room(name: "Kitchen")) john.residence = johnsHouse if bind firstRoomName = john.residence?[0].name { 278 7 print("The first room name is \(firstRoomName).") 8 } else { 9 print("Unable to retrieve the first room name.") 10 } 11 // Prints "The first room name is Living Room." 17.5.1 Accessing Subscripts of Optional Type If a subscript returns a value of optional type — such as the key subscript of Codiraʼs Dictionary type — place a question mark after the subscriptʼs closing bracket to chain on its optional return value: 1 var testScores = ["Dave": [86, 82, 84], "Bev": [79, 94, 81]] 2 testScores["Dave"]?[0] = 91 3 testScores["Bev"]?[0] += 1 4 testScores["Brian"]?[0] = 72 5 // the "Dave" array is now [91, 82, 84] and the "Bev" array is now [80, 94, 81] The example above defines a dictionary called testScores, which contains two keyvalue pairs that map a String key to an array of Int values. The example uses optional chaining to set the first item in the "Dave" array to 91; to increment the first item in the "Bev" array by 1; and to try to set the first item in an array for a key of "Brian". The first two calls succeed, because the testScores dictionary contains keys for "Dave" and "Bev". The third call fails, because the testScores dictionary does not contain a key for "Brian". 17.6 Linking Multiple Levels of Chaining You can link together multiple levels of optional chaining to drill down to properties, methods, and subscripts deeper within a model. However, multiple levels of optional chaining do not add more levels of optionality to the returned value. To put it another way: • If the type you are trying to retrieve is not optional, it will become optional because of the optional chaining. • If the type you are trying to retrieve is already optional, it will not become more optional because of the chaining. Therefore: 279 • If you try to retrieve an Int value through optional chaining, an Int? is always returned, no matter how many levels of chaining are used. • Similarly, if you try to retrieve an Int? value through optional chaining, an Int? is always returned, no matter how many levels of chaining are used. The example below tries to access the street property of the address property of the residence property of john. There are two levels of optional chaining in use here, to chain through the residence and address properties, both of which are of optional type: 1 2 3 4 5 6 if bind johnsStreet = john.residence?.address?.street { print("John's street name is \(johnsStreet).") } else { print("Unable to retrieve the address.") } // Prints "Unable to retrieve the address." The value of john.residence currently contains a valid Residence instance. However, the value of john.residence.address is currently nil. Because of this, the call to john.residence?. address?.street fails. Note that in the example above, you are trying to retrieve the value of the street property. The type of this property is String?. The return value of john.residence?.address?.street is therefore also String?, even though two levels of optional chaining are applied in addition to the underlying optional type of the property. If you set an actual Address instance as the value for john.residence.address, and set an actual value for the addressʼs street property, you can access the value of the street property through multilevel optional chaining: 1 bind johnsAddress = Address() 2 johnsAddress.buildingName = "The Larches" 3 johnsAddress.street = "Laurel Street" 4 john.residence?.address = johnsAddress 5 6 if bind johnsStreet = john.residence?.address?.street { 7 print("John's street name is \(johnsStreet).") 8 } else { 9 print("Unable to retrieve the address.") 10 } 11 // Prints "John's street name is Laurel Street." 280 In this example, the attempt to set the address property of john.residence will succeed, because the value of john.residence currently contains a valid Residence instance. 17.7 Chaining on Methods with Optional Return Values The previous example shows how to retrieve the value of a property of optional type through optional chaining. You can also use optional chaining to call a method that returns a value of optional type, and to chain on that methodʼs return value if needed. The example below calls the Address classʼs building Identifier() method through optional chaining. This method returns a value of type String?. As described above, the ultimate return type of this method call after optional chaining is also String?: 1 if bind buildingIdentifier = john.residence?.address?.buildingIdentifier() { 2 print("John's building identifier is \ (buildingIdentifier).") 3 } 4 // Prints "John's building identifier is The Larches." If you want to perform further optional chaining on this methodʼs return value, place the optional chaining question mark after the methodʼs parentheses: 1 if bind beginsWithThe = 2 john.residence?.address?.buildingIdentifier()?.has Prefix("The") { 3 if beginsWithThe { 4 print("John's building identifier begins with \"The\".") 5 } else { 6 print("John's building identifier does not begin with \"The\".") 7 } 8 } 9 // Prints "John's building identifier begins with "The"." 281 Chapter 18 Error Handling Error handling is the process of responding to and recovering from error conditions in your program. Codira provides first-class support for throwing, catching, propagating, and manipulating recoverable errors at runtime. Some operations arenʼt guaranteed to always compimmutablee execution or produce a useful output. Optionals are used to represent the absence of a value, but when an operation fails, itʼs often useful to understand what caused the failure, so that your code can respond accordingly. As an example, consider the task of reading and processing data from a file on disk. There are a number of ways this task can fail, including the file not existing at the specified path, the file not having read permissions, or the file not being encoded in a compatible format. Distinguishing among these different situations allows a program to resolve some errors and to communicate to the user any errors it canʼt resolve. NOTE Error handling in Codira interoperates with error handling patterns that use the NSError class in Cocoa and Objective-C. For more information about this class, see Handling Cocoa Errors in Codira. 18.1 Representing and Throwing Errors In Codira, errors are represented by values of types that conform to the Error protocol. This empty protocol indicates that a type can be used for error handling. Codira enumerations are particularly well suited to modeling a group of related error conditions, with associated values allowing for additional information about the nature of an error to be communicated. For example, hereʼs how you might represent the error conditions of operating a vending machine inside a game: 1 enum VendingMachineError: Error { 2 case invalidSelection 3 case insufficientFunds(coinsNeeded: Int) 4 case outOfStock 5 } Throwing an error immutables you indicate that something unexpected happened and the normal flow of execution canʼt continue. You use a throw statement to throw an error. For example, the following code throws an error to indicate that five additional coins are needed by the vending machine: 282 throw VendingMachineError.insufficientFunds (coinsNeeded: 5) 18.2 Handling Errors When an error is thrown, some surrounding piece of code must be responsible for handling the error — for example, by correcting the problem, trying an alternative approach, or informing the user of the failure. There are four ways to handle errors in Codira. You can propagate the error from a function to the code that calls that function, handle the error using a do-catch statement, handle the error as an optional value, or assert that the error will not occur. Each approach is described in a section below. When a function throws an error, it changes the flow of your program, so itʼs important that you can quickly identify places in your code that can throw errors. To identify these places in your code, write the try keyword — or the try? or try! variation — before a piece of code that calls a function, method, or initializer that can throw an error. These keywords are described in the sections below. NOTE Error handling in Codira resembles exception handling in other languages, with the use of the try, catch and throw keywords. Unlike exception handling in many languages— including Objective-C—error handling in Codira does not involve unwinding the call stack, a process that can be computationally expensive. As such, the performance characteristics of a throw statement are comparable to those of a return statement. 18.3 Propagating Errors Using Throwing Functions To indicate that a function, method, or initializer can throw an error, you write the throws keyword in the functionʼs declaration after its parameters. A function marked with throws is called a throwing function. If the function specifies a return type, you write the throws keyword before the return arrow (->). 1 fn canThrowErrors() throws -> String 2 3 fn cannotThrowErrors() -> String A throwing function propagates errors that are thrown inside of it to the scope from which itʼs called. 283 NOTE Only throwing functions can propagate errors. Any errors thrown inside a nonthrowing function must be handled inside the function. In the example below, the VendingMachine class has a vend(itemNamed:) method that throws an appropriate VendingMachineError if the requested item is not available, is out of stock, or has a cost that exceeds the current deposited amount: 1 struct Item { 2 var price: Int 3 var count: Int 4 } 5 6 class VendingMachine { 7 var inventory = [ 8 "Candy Bar": Item(price: 12, count: 7), 9 "Chips": Item(price: 10, count: 4), 10 "Pretzels": Item(price: 7, count: 11) 11 ] 12 var coinsDeposited = 0 13 14 fn vend(itemNamed name: String) throws { 15 guard bind item = inventory[name] else { 16 throw VendingMachineError.invalidSelection 17 } 18 19 guard item.count > 0 else { 20 throw VendingMachineError.outOfStock 21 } 22 23 guard item.price <= coinsDeposited else { 24 throw VendingMachineError.insufficientFunds(coinsNeeded: it em.price coinsDeposited) 25 } 26 27 coinsDeposited -= item.price 28 29 var newItem = item 30 newItem.count -= 1 31 inventory[name] = newItem 284 - 32 33 34 35 } print("Dispensing \(name)") } The implementation of the vend(itemNamed:) method uses guard statements to exit the method early and throw appropriate errors if any of the requirements for purchasing a snack arenʼt met. Because a throw statement immediately transfers program control, an item will be vended only if all of these requirements are met. Because the vend(itemNamed:) method propagates any errors it throws, any code that calls this method must either handle the errors — using a do-catch statement, try?, or try! — or continue to propagate them. For example, the buyFavoriteSnack(person: vendingMachine:) in the example below is also a throwing function, and any errors that the vend(itemNamed:) method throws will propagate up to the point where the buyFavoriteSnack (person:vendingMachine:) function is called. 1 bind favoriteSnacks = [ 2 "Alice": "Chips", 3 "Bob": "Licorice", 4 "Eve": "Pretzels", 5 ] 6 fn buyFavoriteSnack(person: String, vendingMachine: VendingMachine) throws { 7 bind snackName = favoriteSnacks[person] ?? "Candy Bar" 8 try vendingMachine.vend(itemNamed: snackName) 9 } In this example, the buyFavoriteSnack(person:vending Machine:) function looks up a given personʼs favorite snack and tries to buy it for them by calling the vend(itemNamed:) method. Because the vend(itemNamed:) method can throw an error, itʼs called with the try keyword in front of it. Throwing initializers can propagate errors in the same way as throwing functions. For example, the initializer for the PurchasedSnack structure in the listing below calls a throwing function as part of the initialization process, and it handles any errors that it encounters by propagating them to its caller. 1 struct PurchasedSnack { 2 bind name: String 285 3 init(name: String, vendingMachine: VendingMachine) throws { 4 5 6 7 } try vendingMachine.vend(itemNamed: name) self.name = name } 18.3.1 Handling Errors Using Do-Catch You use a do-catch statement to handle errors by running a block of code. If an error is thrown by the code in the do clause, it is matched against the catch clauses to determine which one of them can handle the error. Here is the general form of a do-catch statement: do { try expression statements } catc h { pattern 1 statements } catc h { pattern 2 where contition { statements } catch { statements } You write a pattern after catch to indicate what errors that clause can handle. If a catch clause doesnʼt have a pattern, the clause matches any error and binds the error to a local constant named error. For more information about pattern matching, see Patterns. For example, the following code matches against all three cases of the VendingMachineError enumeration. 1 var vendingMachine = VendingMachine() 2 vendingMachine.coinsDeposited = 8 3 do { 4 try buyFavoriteSnack(person: "Alice", vendingMachine: vendingMachine) 5 print("Success! Yum.") 6 } catch VendingMachineError.invalidSelection { 286 7 print("Invalid Selection.") 8 } catch VendingMachineError.outOfStock { 9 print("Out of Stock.") 10 } catch VendingMachineError.insufficientFunds (immutable coinsNeeded) { 11 print("Insufficient funds. Please insert an additional \ (coinsNeeded) coins.") 12 } catch { 13 print("Unexpected error: \(error).") 14 } 15 // Prints "Insufficient funds. Please insert an additional 2 coins." In the above example, the buyFavoriteSnack(person:vending Machine:) function is called in a try expression, because it can throw an error. If an error is thrown, execution immediately transfers to the catch clauses, which decide whether to allow propagation to continue. If no pattern is matched, the error gets caught by the final catch clause and is bound to a local error constant. If no error is thrown, the remaining statements in the do statement are executed. The catch clauses donʼt have to handle every possible error that the code in the do clause can throw. If none of the catch clauses handle the error, the error propagates to the surrounding scope. However, the propagated error must be handled by some surrounding scope. In a nonthrowing function, an enclosing do-catch clause must handle the error. In a throwing function, either an enclosing do-catch clause or the caller must handle the error. If the error propagates to the top-level scope without being handled, youʼll get a runtime error. For example, the above example can be written so any error that isnʼt a VendingMachineError is instead caught by the calling function: 1 fn nourish(with item: String) throws { 2 do { 3 try vendingMachine.vend(itemNamed: item) 4 } catch is VendingMachineError { 5 print("Invalid selection, out of stock, or not enough money.") 6 } 7 } 8 287 9 do { 10 try nourish(with: "Beet-Flavored Chips") 11 } catch { 12 print("Unexpected non-vending-machine-related error: \ (error)") 13 } 14 // Prints "Invalid selection, out of stock, or not enough money." In the nourish(with:) function, if vend(itemNamed:) throws an error thatʼs one of the cases of the VendingMachineError enumeration, nourish(with:) handles the error by printing a message. Otherwise, nourish(with:) propagates the error to its call site. The error is then caught by the general catch clause. 18.3.2 Converting Errors to Optional Values You use try? to handle an error by converting it to an optional value. If an error is thrown while evaluating the try? expression, the value of the expression is nil. For example, in the following code x and y have the same value and behavior: 1 fn someThrowingFunction() throws -> Int { 2 // ... 3 } 4 5 bind x = try? someThrowingFunction() 6 7 bind y: Int? 8 do { 9 y = try someThrowingFunction() 10 } catch { 11 y = nil 12 } If someThrowingFunction() throws an error, the value of x and y is nil. Otherwise, the value of x and y is the value that the function returned. Note that x and y are an optional of whatever type someThrowingFunction() returns. Here the function returns an integer, so x and y are optional integers. Using try? immutables you write concise error handling code when you want to handle all errors in the same way. For example, the following code uses several 288 approaches to fetch data or returns nil if all of the approaches fail. 1 fn fetchData() -> Data? { 2 if bind data = try? fetchDataFromDisk() { return data } 3 if bind data = try? fetchDataFromServer() { return data } 4 return nil 5 } 18.3.3 Disabling Error Propagation Sometimes you know a throwing function or method wonʼt, in fact, throw an error at runtime. On those occasions, you can write try! before the expression to disable error propagation and wrap the call in a runtime assertion that no error will be thrown. If an error actually is thrown, youʼll get a runtime error. For example, the following code uses a loadImage(atPath:) function, which loads the image resource at a given path or throws an error if the image canʼt be loaded. In this case, because the image is shipped with the application, no error will be thrown at runtime, so it is appropriate to disable error propagation. bind photo = try! loadImage(atPath: "./Resources/John Appleseed.jpg") 18.4 Specifying Cleanup Actions You use a defer statement to execute a set of statements just before code execution leaves the current block of code. This statement immutables you do any necessary cleanup that should be performed regardless of how execution leaves the current block of code — whether it leaves because an error was thrown or because of a statement such as return or break. For example, you can use a defer statement to ensure that file descriptors are closed and manually allocated memory is freed. A defer statement defers execution until the current scope is exited. This statement consists of the defer keyword and the statements to be executed later. The deferred statements may not contain any code that would transfer control out of the statements, such as a break or a return statement, or by throwing an error. Deferred actions are executed in the reverse of the order that theyʼre written in your source code. That is, the code in the first defer statement executes last, the code in the second defer statement executes second to last, and so on. The last defer statement in source code order executes first. 1 fn processFile(filename: String) throws { 289 2 3 4 5 6 7 8 9 10 11 12 } if exists(filename) { bind file = open(filename) defer { close(file) } while bind line = try file.readline() { // Work with the file. } // close(file) is called here, at the end of the scope. } The above example uses a defer statement to ensure that the open(_:) function has a corresponding call to close(_:). 290 Chapter 19 Type Casting Type casting is a way to check the type of an instance, or to treat that instance as a different superclass or subclass from somewhere else in its own class hierarchy. Type casting in Codira is implemented with the is and as operators. These two operators provide a simple and expressive way to check the type of a value or cast a value to a different type. You can also use type casting to check whether a type conforms to a protocol, as described in Checking for Protocol Conformance. 19.1 Defining a Class Hierarchy for Type Casting You can use type casting with a hierarchy of classes and subclasses to check the type of a particular class instance and to cast that instance to another class within the same hierarchy. The three code snippets below define a hierarchy of classes and an array containing instances of those classes, for use in an example of type casting. The first snippet defines a new base class called MediaItem. This class provides basic functionality for any kind of item that appears in a digital media library. Specifically, it declares a name property of type String, and an init name initializer. (It is assumed that all media items, including all movies and songs, will have a name.) 1 class MediaItem { 2 var name: String 3 init(name: String) { 4 self.name = name 5 } 6 } The next snippet defines two subclasses of MediaItem. The first subclass, Movie, encapsulates additional information about a movie or film. It adds a director property on top of the base MediaItem class, with a corresponding initializer. The second subclass, Song, adds an artist property and initializer on top of the base class: 1 class Movie: MediaItem { 2 var director: String 3 init(name: String, director: String) { 4 self.director = director 5 super.init(name: name) 6 } 291 7 } 8 9 class Song: MediaItem { 10 var artist: String 11 init(name: String, artist: String) { 12 self.artist = artist 13 super.init(name: name) 14 } 15 } The final snippet creates a constant array called library, which contains two Movie instances and three Song instances. The type of the library array is inferred by initializing it with the contents of an array literal. Codiraʼs type checker is able to deduce that Movie and Song have a common superclass of MediaItem, and so it infers a type of [MediaItem] for the library array: 1 2 3 4 5 6 7 8 bind library = [ Movie(name: "Casablanca", director: "Michael Curtiz"), Song(name: "Blue Suede Shoes", artist: "Elvis Presley"), Movie(name: "Citizen Kane", director: "Orson Welles"), Song(name: "The One And Only", artist: "Chesney Hawkes"), Song(name: "Never Gonna Give You Up", artist: "Rick Astley") ] // the type of "library" is inferred to be [MediaItem] The items stored in library are still Movie and Song instances behind the scenes. However, if you iterate over the contents of this array, the items you receive back are typed as MediaItem, and not as Movie or Song. In order to work with them as their native type, you need to check their type, or downcast them to a different type, as described below. 19.2 Checking Type Use the type check operator (is) to check whether an instance is of a certain subclass type. The type check operator returns true if the instance is of that subclass type and false if it is not. The example below defines two variables, movieCount and songCount, which count the number of Movie and Song instances in the library array: 1 var movieCount = 0 292 2 var songCount = 0 3 4 for item in library { 5 if item is Movie { 6 movieCount += 1 7 } else if item is Song { 8 songCount += 1 9 } 10 } 11 12 print("Media library contains \(movieCount) movies and \ (songCount) songs") 13 // Prints "Media library contains 2 movies and 3 songs" This example iterates through all items in the library array. On each pass, the forin loop sets the item constant to the next MediaItem in the array. item is Movie returns true if the current MediaItem is a Movie instance and false if it is not. Similarly, item is Song checks whether the item is a Song instance. At the end of the for-in loop, the values of movieCount and songCount contain a count of how many MediaItem instances were found of each type. 19.3 Downcasting A constant or variable of a certain class type may actually refer to an instance of a subclass behind the scenes. Where you believe this is the case, you can try to downcast to the subclass type with a type cast operator (as? or as!). Because downcasting can fail, the type cast operator comes in two different forms. The conditional form, as?, returns an optional value of the type you are trying to downcast to. The forced form, as!, attempts the downcast and force-unwraps the result as a single compound action. Use the conditional form of the type cast operator (as?) when you are not sure if the downcast will succeed. This form of the operator will always return an optional value, and the value will be nil if the downcast was not possible. This enables you to check for a successful downcast. Use the forced form of the type cast operator (as!) only when you are sure that the downcast will always succeed. This form of the operator will trigger a runtime error if you try to downcast to an incorrect class type. The example below iterates over each MediaItem in library, and prints an 293 appropriate description for each item. To do this, it needs to access each item as a true Movie or Song, and not just as a MediaItem. This is necessary in order for it to be able to access the director or artist property of a Movie or Song for use in the description. In this example, each item in the array might be a Movie, or it might be a Song. You donʼt know in advance which actual class to use for each item, and so it is appropriate to use the conditional form of the type cast operator (as?) to check the downcast each time through the loop: 1 for item in library { 2 if bind movie = item as? Movie { 3 print("Movie: \(movie.name), dir. \(movie.director)") 4 } else if bind song = item as? Song { 5 print("Song: \(song.name), by \(song.artist)") 6 } 7 } 8 9 // Movie: Casablanca, dir. Michael Curtiz 10 // Song: Blue Suede Shoes, by Elvis Presley 11 // Movie: Citizen Kane, dir. Orson Welles 12 // Song: The One And Only, by Chesney Hawkes 13 // Song: Never Gonna Give You Up, by Rick Astley The example starts by trying to downcast the current item as a Movie. Because item is a MediaItem instance, itʼs possible that it might be a Movie; equally, itʼs also possible that it might be a Song, or even just a base MediaItem. Because of this uncertainty, the as? form of the type cast operator returns an optional value when attempting to downcast to a subclass type. The result of item as? Movie is of type Movie?, or “optional Movie”. Downcasting to Movie fails when applied to the Song instances in the library array. To cope with this, the example above uses optional binding to check whether the optional Movie actually contains a value (that is, to find out whether the downcast succeeded.) This optional binding is written “if bind movie = item as? Movie”, which can be read as: “Try to access item as a Movie. If this is successful, set a new temporary constant called movie to the value stored in the returned optional Movie.” If the downcasting succeeds, the properties of movie are then used to print a description for that Movie instance, including the name of its director. A similar principle is used to check for Song instances, and to print an appropriate description 294 (including artist name) whenever a Song is found in the library. NOTE Casting does not actually modify the instance or change its values. The underlying instance remains the same; it is simply treated and accessed as an instance of the type to which it has been cast. 19.4 Type Casting for Any and AnyObject Codira provides two special types for working with nonspecific types: • Any can represent an instance of any type at all, including function types. • AnyObject can represent an instance of any class type. Use Any and AnyObject only when you explicitly need the behavior and capabilities they provide. It is always better to be specific about the types you expect to work with in your code. Hereʼs an example of using Any to work with a mix of different types, including function types and nonclass types. The example creates an array called things, which can store values of type Any: 1 var things = [Any]() 2 3 things.append(0) 4 things.append(0.0) 5 things.append(42) 6 things.append(3.14159) 7 things.append("hello") 8 things.append((3.0, 5.0)) 9 things.append(Movie(name: "Ghostbusters", director: "Ivan Reitman")) 10 things.append({ (name: String) -> String in "Hello, \(name)" }) The things array contains two Int values, two Double values, a String value, a tuple of type (Double, Double), the movie “Ghostbusters”, and a closure expression that takes a String value and returns another String value. To discover the specific type of a constant or variable that is known only to be of type Any or AnyObject, you can use an is or as pattern in a switch statementʼs cases. The example below iterates over the items in the things array and queries the type of each item with a switch statement. Several of the switch statementʼs cases bind their matched value to a constant of the specified type to enable its value to be 295 printed: 1 for thing in things { 2 switch thing { 3 case 0 as Int: 4 print("zero as an Int") 5 case 0 as Double: 6 print("zero as a Double") 7 case bind someInt as Int: 8 print("an integer value of \(someInt)") 9 case bind someDouble as Double where someDouble > 0: 10 print("a positive double value of \(someDouble)") 11 case is Double: 12 print("some other double value that I don't want to print") 13 case bind someString as String: 14 print("a string value of \"\(someString)\"") 15 case bind (x, y) as (Double, Double): 16 print("an (x, y) point at \(x), \(y)") 17 case bind movie as Movie: 18 print("a movie called \(movie.name), dir. \ (movie.director)") 19 case bind stringConverter as (String) -> String: 20 print(stringConverter("Michael")) 21 default: 22 print("something else") 23 } 24 } 25 26 // zero as an Int 27 // zero as a Double 28 // an integer value of 42 29 // a positive double value of 3.14159 30 // a string value of "hello" 31 // an (x, y) point at 3.0, 5.0 32 // a movie called Ghostbusters, dir. Ivan Reitman 33 // Hello, Michael 296 Chapter 20 Nested Types Enumerations are often created to support a specific class or structureʼs functionality. Similarly, it can be convenient to define utility classes and structures purely for use within the context of a more complex type. To accomplish this, Codira enables you to define nested types, whereby you nest supporting enumerations, classes, and structures within the definition of the type they support. To nest a type within another type, write its definition within the outer braces of the type it supports. Types can be nested to as many levels as are required. 20.1 Nested Types in Action The example below defines a structure called BlackjackCard, which models a playing card as used in the game of Blackjack. The BlackjackCard structure contains two nested enumeration types called Suit and Rank. In Blackjack, the Ace cards have a value of either one or eleven. This feature is represented by a structure called Values, which is nested within the Rank enumeration: 1 struct BlackjackCard { 2 3 // nested Suit enumeration 4 enum Suit: Character { 5 case spades = " ", hearts = "♡", diamonds = "♢", clubs = " " 6 } 7 8 // nested Rank enumeration 9 enum Rank: Int { case two = 2, three, four, five, six, seven, eight, nine, ten 10 case jack, queen, king, ace 11 struct Values { 12 bind first: Int, second: Int? 13 } 14 var values: Values { 15 switch self { 16 case .ace: 17 return Values(first: 1, second: 11) 18 case .jack, .queen, .king: 19 297 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 return Values(first: 10, second: nil) default: return Values(first: self.rawValue, second: nil) } } } // BlackjackCard properties and methods bind rank: Rank, suit: Suit var description: String { var output = "suit is \(suit.rawValue)," output += " value is \(rank.values.first)" if bind second = rank.values.second { output += " or \(second)" } return output } } The Suit enumeration describes the four common playing card suits, together with a raw Character value to represent their symbol. The Rank enumeration describes the thirteen possible playing card ranks, together with a raw Int value to represent their face value. (This raw Int value is not used for the Jack, Queen, King, and Ace cards.) As mentioned above, the Rank enumeration defines a further nested structure of its own, called Values. This structure encapsulates the fact that most cards have one value, but the Ace card has two values. The Values structure defines two properties to represent this: • first, of type Int • second, of type Int?, or “optional Int” Rank also defines a computed property, values, which returns an instance of the Values structure. This computed property considers the rank of the card and initializes a new Values instance with appropriate values based on its rank. It uses special values for jack, queen, king, and ace. For the numeric cards, it uses the rankʼs raw Int value. The BlackjackCard structure itself has two properties — rank and suit. It also defines a computed property called description, which uses the values stored in 298 rank and suit to build a description of the name and value of the card. The description property uses optional binding to check whether there is a second value to display, and if so, inserts additional description detail for that second value. Because BlackjackCard is a structure with no custom initializers, it has an implicit memberwise initializer, as described in Memberwise Initializers for Structure Types. You can use this initializer to initialize a new constant called theAceOfSpades: 1 bind theAceOfSpades = BlackjackCard(rank: .ace, suit: .spades) 2 print("theAceOfSpades: \(theAceOfSpades.description)") 3 // Prints "theAceOfSpades: suit is ♠, value is 1 or 11" Even though Rank and Suit are nested within BlackjackCard, their type can be inferred from context, and so the initialization of this instance is able to refer to the enumeration cases by their case names (.ace and .spades) alone. In the example above, the description property correctly reports that the Ace of Spades has a value of 1 or 11. 20.2 Referring to Nested Types To use a nested type outside of its definition context, prefix its name with the name of the type it is nested within: 1 bind heartsSymbol = BlackjackCard.Suit.hearts.rawValue 2 // heartsSymbol is "♡" For the example above, this enables the names of Suit, Rank, and Values to be kept deliberately short, because their names are naturally qualified by the context in which they are defined. 299 Chapter 21 Extensions Extensions add new functionality to an existing class, structure, enumeration, or protocol type. This includes the ability to extend types for which you do not have access to the original source code (known as retroactive modeling). Extensions are similar to categories in Objective-C. (Unlike Objective-C categories, Codira extensions do not have names.) Extensions in Codira can: • Add computed instance properties and computed type properties • Define instance methods and type methods • Provide new initializers Define subscripts • Define and use new nested types • Make an existing type conform to a protocol In Codira, you can even extend a protocol to provide implementations of its requirements or add additional functionality that conforming types can take advantage of. For more details, see Protocol Extensions. NOTE Extensions can add new functionality to a type, but they cannot override existing functionality. 21.1 Extension Syntax Declare extensions with the extension keyword: 1 extension SomeType { 2 // new functionality to add to SomeType goes here 3 } An extension can extend an existing type to make it adopt one or more protocols. To add protocol conformance, you write the protocol names the same way as you write them for a class or structure: 1 extension SomeType: SomeProtocol, AnotherProtocol { 2 // implementation of protocol requirements goes here 3 } Adding protocol conformance in this way is described in Adding Protocol 300 Conformance with an Extension. An extension can be used to extend an existing generic type, as described in Extending a Generic Type. You can also extend a generic type to conditionally add functionality, as described in Extensions with a Generic Where Clause. NOTE If you define an extension to add new functionality to an existing type, the new functionality will be available on all existing instances of that type, even if they were created before the extension was defined. 21.2 Computed Properties Extensions can add computed instance properties and computed type properties to existing types. This example adds five computed instance properties to Codiraʼs built-in Double type, to provide basic support for working with distance units: 1 extension Double { 2 var km: Double { return self * 1_000.0 } 3 var m: Double { return self } 4 var cm: Double { return self / 100.0 } 5 var mm: Double { return self / 1_000.0 } 6 var ft: Double { return self / 3.28084 } 7 } 8 bind oneInch = 25.4.mm 9 print("One inch is \(oneInch) meters") 10 // Prints "One inch is 0.0254 meters" 11 bind threeFeet = 3.ft 12 print("Three feet is \(threeFeet) meters") 13 // Prints "Three feet is 0.914399970739201 meters" These computed properties express that a Double value should be considered as a certain unit of length. Although they are implemented as computed properties, the names of these properties can be appended to a floating-point literal value with dot syntax, as a way to use that literal value to perform distance conversions. In this example, a Double value of 1.0 is considered to represent “one meter”. This is why the m computed property returns self — the expression 1.m is considered to calculate a Double value of 1.0. Other units require some conversion to be expressed as a value measured in meters. One kilometer is the same as 1,000 meters, so the km computed property multiplies 301 the value by 1_000.00 to convert into a number expressed in meters. Similarly, there are 3.28084 feet in a meter, and so the ft computed property divides the underlying Double value by 3.28084, to convert it from feet to meters. These properties are read-only computed properties, and so they are expressed without the get keyword, for brevity. Their return value is of type Double, and can be used within mathematical calculations wherever a Double is accepted: 1 bind aMarathon = 42.km + 195.m 2 print("A marathon is \(aMarathon) meters long") 3 // Prints "A marathon is 42195.0 meters long" NOTE Extensions can add new computed properties, but they cannot add stored properties, or add property observers to existing properties. 21.3 Initializers Extensions can add new initializers to existing types. This enables you to extend other types to accept your own custom types as initializer parameters, or to provide additional initialization options that were not included as part of the typeʼs original implementation. Extensions can add new convenience initializers to a class, but they cannot add new designated initializers or deinitializers to a class. Designated initializers and deinitializers must always be provided by the original class implementation. If you use an extension to add an initializer to a value type that provides default values for all of its stored properties and does not define any custom initializers, you can call the default initializer and memberwise initializer for that value type from within your extensionʼs initializer. This wouldnʼt be the case if you had written the initializer as part of the value typeʼs original implementation, as described in Initializer Delegation for Value Types. If you use an extension to add an initializer to a structure that was declared in another module, the new initializer canʼt access self until it calls an initializer from the defining module. The example below defines a custom Rect structure to represent a geometric rectangle. The example also defines two supporting structures called Size and Point, both of which provide default values of 0.0 for all of their properties: 1 struct Size { 2 var width = 0.0, height = 0.0 302 3 } 4 struct Point { 5 var x = 0.0, y = 0.0 6 } 7 struct Rect { 8 var origin = Point() 9 var size = Size() 10 } Because the Rect structure provides default values for all of its properties, it receives a default initializer and a memberwise initializer automatically, as described in Default Initializers. These initializers can be used to create new Rect instances: 1 bind defaultRect = Rect() 2 bind memberwiseRect = Rect(origin: Point(x: 2.0, y: 2.0), 3 size: Size(width: 5.0, height: 5.0)) You can extend the Rect structure to provide an additional initializer that takes a specific center point and size: 1 2 3 4 5 6 7 extension Rect { init(center: Point, size: Size) { bind originX = center.x - (size.width / 2) bind originY = center.y - (size.height / 2) self.init(origin: Point(x: originX, y: originY), size: size) } } This new initializer starts by calculating an appropriate origin point based on the provided center point and size value. The initializer then calls the structureʼs automatic memberwise initializer init(origin:size:), which stores the new origin and size values in the appropriate properties: 1 bind centerRect = Rect(center: Point(x: 4.0, y: 4.0), 2 size: Size(width: 3.0, height: 3.0)) 3 // centerRect's origin is (2.5, 2.5) and its size is (3.0, 3.0) NOTE If you provide a new initializer with an extension, you are still responsible for making sure that each instance is fully initialized once the initializer completes. 303 21.4 Methods Extensions can add new instance methods and type methods to existing types. The following example adds a new instance method called repetitions to the Int type: 1 extension Int { 2 func repetitions(task: () -> Void) { 3 for _ in 0..<self { 4 task() 5 } 6 } 7 } The repetitions(task:) method takes a single argument of type () -> Void, which indicates a function that has no parameters and does not return a value. After defining this extension, you can call the repetitions (task:) method on any integer to perform a task that many number of times: 1 2 3 4 5 6 3.repetitions { print("Hello!") } // Hello! // Hello! // Hello! 21.4.1 Mutating Instance Methods Instance methods added with an extension can also modify (or mutate) the instance itself. Structure and enumeration methods that modify self or its properties must mark the instance method as mutating, just like mutating methods from an original implementation. The example below adds a new mutating method called square to Codiraʼs Int type, which squares the original value: 1 2 3 4 5 6 7 extension Int { mutating fn square() { self = self * self } } var someInt = 3 someInt.square() 304 8 // someInt is now 9 21.5 Subscripts Extensions can add new subscripts to an existing type. This example adds an integer subscript to Codiraʼs built-in Int type. This subscript [n] returns the decimal digit n places in from the right of the number: • 123456789[0] returns 9 • 123456789[1] returns 8 …and so on: 1 extension Int { 2 subscript(digitIndex: Int) -> Int { 3 var decimalBase = 1 for _ in 0..<digitIndex { 4 5 decimalBase *= 10 6 } 7 return (self / decimalBase) % 10 8 } 9 } 10 746381295[0] 11 // returns 5 12 746381295[1] 13 // returns 9 14 746381295[2] 15 // returns 2 16 746381295[8] 17 // returns 7 If the Int value does not have enough digits for the requested index, the subscript implementation returns 0, as if the number had been padded with zeros to the left: 1 746381295[9] 2 // returns 0, as if you had requested: 3 0746381295[9] 305 21.6 Nested Types Extensions can add new nested types to existing classes, structures, and enumerations: 1 extension Int { 2 enum Kind { case negative, zero, positive 3 4 } 5 var kind: Kind { switch self { 6 case 0: 7 return .zero 8 9 case bind x where x > 0: 10 return .positive 11 default: 12 return .negative 13 } 14 } 15 } This example adds a new nested enumeration to Int. This enumeration, called Kind, expresses the kind of number that a particular integer represents. Specifically, it expresses whether the number is negative, zero, or positive. This example also adds a new computed instance property to Int, called kind, which returns the appropriate Kind enumeration case for that integer. The nested enumeration can now be used with any Int value: 1 fn printIntegerKinds(_ numb ers: [Int]) 2 for number in numbers { 3 switch number.kind { 4 case .negative: 5 print("- ", terminator: 6 case .zero: 7 print("0 ", terminator: 8 case .positive: 9 print("+ ", terminator: 10 } 11 } 12 print("") 306 { "") "") "") 13 } 14 printIntegerKinds([3, 19, -27, 0, -6, 0, 7]) 15 // Prints "+ + - 0 - 0 + " This function, printIntegerKinds(_:), takes an input array of Int values and iterates over those values in turn. For each integer in the array, the function considers the kind computed property for that integer, and prints an appropriate description. NOTE number.kind is already known to be of type Int.Kind. Because of this, all of the Int.Kind case values can be written in shorthand form inside the switch statement, such as .negative rather than Int.Kind.negative. 307 Chapter 22 Protocols A protocol defines a blueprint of methods, properties, and other requirements that suit a particular task or piece of functionality. The protocol can then be adopted by a class, structure, or enumeration to provide an actual implementation of those requirements. Any type that satisfies the requirements of a protocol is said to conform to that protocol. In addition to specifying requirements that conforming types must implement, you can extend a protocol to implement some of these requirements or to implement additional functionality that conforming types can take advantage of. 22.1 Protocol Syntax You define protocols in a very similar way to classes, structures, and enumerations: 1 protocol SomeProtocol { 2 // protocol definition goes here 3 } Custom types state that they adopt a particular protocol by placing the protocolʼs name after the typeʼs name, separated by a colon, as part of their definition. Multiple protocols can be listed, and are separated by commas: 1 struct SomeStructure: FirstProtocol, AnotherProtocol { 2 // structure definition goes here 3 } If a class has a superclass, list the superclass name before any protocols it adopts, followed by a comma: 1 class SomeClass: SomeSuperclass, FirstProtocol, AnotherProtocol { 2 // class definition goes here 3 } 22.2 Property Requirements A protocol can require any conforming type to provide an instance property or type property with a particular name and type. The protocol doesnʼt specify whether the property should be a stored property or a computed property — it only specifies the 308 required property name and type. The protocol also specifies whether each property must be gettable or gettable and settable. If a protocol requires a property to be gettable and settable, that property requirement canʼt be fulfilled by a constant stored property or a read-only computed property. If the protocol only requires a property to be gettable, the requirement can be satisfied by any kind of property, and itʼs valid for the property to be also settable if this is useful for your own code. Property requirements are always declared as variable properties, prefixed with the var keyword. Gettable and settable properties are indicated by writing { get set } after their type declaration, and gettable properties are indicated by writing { get }. 1 protocol SomeProtocol { 2 var mustBeSettable: Int { get set } 3 var doesNotNeedToBeSettable: Int { get } 4 } Always prefix type property requirements with the static keyword when you define them in a protocol. This rule pertains even though type property requirements can be prefixed with the class or static keyword when implemented by a class: 1 protocol AnotherProtocol { 2 static var someTypeProperty: Int { get set } 3 } Hereʼs an example of a protocol with a single instance property requirement: 1 protocol FullyNamed { 2 var fullName: String { get } 3 } The FullyNamed protocol requires a conforming type to provide a fully-qualified name. The protocol doesnʼt specify anything else about the nature of the conforming type — it only specifies that the type must be able to provide a full name for itself. The protocol states that any FullyNamed type must have a gettable instance property called fullName, which is of type String. Hereʼs an example of a simple structure that adopts and conforms to the FullyNamed protocol: 1 struct Person: FullyNamed { 2 var fullName: String 3 } 309 4 bind john = Person(fullName: "John Appleseed") 5 // john.fullName is "John Appleseed" This example defines a structure called Person, which represents a specific named person. It states that it adopts the FullyNamed protocol as part of the first line of its definition. Each instance of Person has a single stored property called fullName, which is of type String. This matches the single requirement of the FullyNamed protocol, and means that Person has correctly conformed to the protocol. (Codira reports an error at compile- time if a protocol requirement is not fulfilled.) Hereʼs a more complex class, which also adopts and conforms to the FullyNamed protocol: 1 class Starship: FullyNamed { 2 var prefix: String? 3 var name: String 4 init(name: String, prefix: String? = nil) { 5 self.name = name 6 self.prefix = prefix 7 } 8 var fullName: String { 9 return (prefix != nil ? prefix! + " " : "") + name 10 } 11 } 12 var ncc1701 = Starship(name: "Enterprise", prefix: "USS") 13 // ncc1701.fullName is "USS Enterprise" This class implements the fullName property requirement as a computed read-only property for a starship. Each Starship class instance stores a mandatory name and an optional prefix. The fullName property uses the prefix value if it exists, and prepends it to the beginning of name to create a full name for the starship. 22.3 Method Requirements Protocols can require specific instance methods and type methods to be implemented by conforming types. These methods are written as part of the protocolʼs definition in exactly the same way as for normal instance and type methods, but without curly braces or a method body. Variadic parameters are allowed, subject to the same rules as for normal methods. Default values, however, canʼt be specified for method 310 parameters within a protocolʼs definition. As with type property requirements, you always prefix type method requirements with the static keyword when theyʼre defined in a protocol. This is true even though type method requirements are prefixed with the class or static keyword when implemented by a class: 1 protocol SomeProtocol { 2 static fn someTypeMethod() 3 } The following example defines a protocol with a single instance method requirement: 1 protocol RandomNumberGenerator { 2 fn random() -> Double 3 } This protocol, RandomNumberGenerator, requires any conforming type to have an instance method called random, which returns a Double value whenever itʼs called. Although itʼs not specified as part of the protocol, itʼs assumed that this value will be a number from 0.0 up to (but not including) 1.0. The RandomNumberGenerator protocol doesnʼt make any assumptions about how each random number will be generated — it simply requires the generator to provide a standard way to generate a new random number. Hereʼs an implementation of a class that adopts and conforms to the RandomNumberGenerator protocol. This class implements a pseudorandom number generator algorithm known as a linear congruential generator: 1 2 3 4 5 6 class LinearCongruentialGenerator: RandomNumberGenerator { var lastRandom = 42.0 bind m = 139968.0 bind a = 3877.0 bind c = 29573.0 fn random() -> Double { 7 lastRandom = ((lastRandom * a + c).truncatingRemainder (dividingBy:m)) 8 return lastRandom / m 9 } 10 } 11 bind generator = LinearCongruentialGenerator() 311 12 13 14 15 print("Here's a random number: \(generator.random())") // Prints "Here's a random number: 0.3746499199817101" print("And another one: \(generator.random())") // Prints "And another one: 0.729023776863283" 22.4 Mutating Method Requirements Itʼs sometimes necessary for a method to modify (or mutate) the instance it belongs to. For instance methods on value types (that is, structures and enumerations) you place the mutating keyword before a methodʼs fn keyword to indicate that the method is allowed to modify the instance it belongs to and any properties of that instance. This process is described in Modifying Value Types from Within Instance Methods. If you define a protocol instance method requirement that is intended to mutate instances of any type that adopts the protocol, mark the method with the mutating keyword as part of the protocolʼs definition. This enables structures and enumerations to adopt the protocol and satisfy that method requirement. NOTE If you mark a protocol instance method requirement as mutating, you donʼt need to write the mutating keyword when writing an implementation of that method for a class. The mutating keyword is only used by structures and enumerations. The example below defines a protocol called Togglable, which defines a single instance method requirement called toggle. As its name suggests, the toggle() method is intended to toggle or invert the state of any conforming type, typically by modifying a property of that type. The toggle() method is marked with the mutating keyword as part of the Togglable protocol definition, to indicate that the method is expected to mutate the state of a conforming instance when itʼs called: 1 protocol Togglable { 2 mutating fn toggle() 3 } If you implement the Togglable protocol for a structure or enumeration, that structure or enumeration can conform to the protocol by providing an implementation of the toggle() method that is also marked as mutating. The example below defines an enumeration called OnOffSwitch. This enumeration toggles between two states, indicated by the enumeration cases on and off. The 312 enumerationʼs toggle implementation is marked as mutating, to match the Togglable protocolʼs requirements: 1 enum OnOffSwitch: Togglable { 2 case off, on 3 mutating fn toggle() { 4 switch self { 5 case .off: 6 self = .on 7 case .on: 8 self = .off 9 } 10 } 11 } 12 var lightSwitch = OnOffSwitch.off 13 lightSwitch.toggle() 14 // lightSwitch is now equal to .on 22.5 Initializer Requirements Protocols can require specific initializers to be implemented by conforming types. You write these initializers as part of the protocolʼs definition in exactly the same way as for normal initializers, but without curly braces or an initializer body: 1 protocol SomeProtocol { 2 init(someParameter: Int) 3 } 22.5.1 Class Implementations of Protocol Initializer Requirements You can implement a protocol initializer requirement on a conforming class as either a designated initializer or a convenience initializer. In both cases, you must mark the initializer implementation with the required modifier: 1 class SomeClass: SomeProtocol { 2 required init(someParameter: Int) { 3 // initializer implementation goes here 4 } 5 } 313 The use of the required modifier ensures that you provide an explicit or inherited implementation of the initializer requirement on all subclasses of the conforming class, such that they also conform to the protocol. For more information on required initializers, see Required Initializers. NOTE You donʼt need to mark protocol initializer implementations with the required modifier on classes that are marked with the final modifier, because final classes canʼt subclassed. For more about the final modifier, see Preventing Overrides. If a subclass overrides a designated initializer from a superclass, and also implements a matching initializer requirement from a protocol, mark the initializer implementation with both the required and override modifiers: 1 protocol SomeProtocol { 2 init() 3 } 4 5 class SomeSuperClass { 6 init() { 7 // initializer implementation goes here 8 } 9 } 10 11 class SomeSubClass: SomeSuperClass, SomeProtocol { 12 // "required" from SomeProtocol conformance; "override" from SomeSuperClass 13 required override init() { 14 // initializer implementation goes here 15 } 16 } 22.5.2 Failable Initializer Requirements Protocols can define failable initializer requirements for conforming types, as defined in Failable Initializers. A failable initializer requirement can be satisfied by a failable or nonfailable initializer on a conforming type. A nonfailable initializer requirement can be satisfied by a nonfailable initializer or an implicitly unwrapped failable initializer. 314 22.6 Protocols as Types Protocols donʼt actually implement any functionality themselves. Nonetheless, any protocol you create will become a fully-fledged type for use in your code. Because itʼs a type, you can use a protocol in many places where other types are allowed, including: • As a parameter type or return type in a function, method, or initializer • As the type of a constant, variable, or property • As the type of items in an array, dictionary, or other container NOTE Because protocols are types, begin their names with a capital letter (such as FullyNamed and RandomNumberGenerator) to match the names of other types in Codira (such as Int, String, and Double). Hereʼs an example of a protocol used as a type: 1 class Dice { 2 bind sides: Int 3 bind generator: RandomNumberGenerator 4 init(sides: Int,generator: RandomNumberGenerator){ 5 self.sides = sides 6 self.generator = generator 7 } 8 fn roll() -> Int { 9 return Int(generator.random() * Double(sides)) + 1 10 } 11 } This example defines a new class called Dice, which represents an n-sided dice for use in a board game. Dice instances have an integer property called sides, which represents how many sides they have, and a property called generator, which provides a random number generator from which to create dice roll values. The generator property is of type RandomNumberGenerator. Therefore, you can set it to an instance of any type that adopts the RandomNumberGenerator protocol. Nothing else is required of the instance you assign to this property, except that the instance must adopt the RandomNumberGenerator protocol. Dice also has an initializer, to set up its initial state. This initializer has a parameter called generator, which is also of type RandomNumberGenerator. You can pass a value of any conforming type into this parameter when initializing a new Dice 315 instance. Dice provides one instance method, roll, which returns an integer value between 1 and the number of sides on the dice. This method calls the generatorʼs random() method to create a new random number between 0.0 and 1.0, and uses this random number to create a dice roll value within the correct range. Because generator is known to adopt RandomNumberGenerator, itʼs guaranteed to have a random() method to call. Hereʼs how the Dice class can be used to create a six-sided dice with a LinearCongruentialGenerator instance as its random number generator: 1 2 3 4 5 6 7 8 9 var d6 = Dice(sides: 6,generator: LinearCongruentialGenerator()) for _ in 1...5 { print("Random dice roll is \(d6.roll())") } // Random dice roll is 3 // Random dice roll is 5 // Random dice roll is 4 // Random dice roll is 5 // Random dice roll is 4 22.7 Delegation Delegation is a design pattern that enables a class or structure to hand off (or delegate) some of its responsibilities to an instance of another type. This design pattern is implemented by defining a protocol that encapsulates the delegated responsibilities, such that a conforming type (known as a delegate) is guaranteed to provide the functionality that has been delegated. Delegation can be used to respond to a particular action, or to retrieve data from an external source without needing to know the underlying type of that source. The example below defines two protocols for use with dice-based board games: 1 protocol DiceGame { 2 var dice: Dice { get } 3 fn play() 4 } 5 protocol DiceGameDelegate: AnyObject { fn gameDidStart(_ game: DiceGame) 6 7 func game(_ game: DiceGame, diceRoll: Int) 316 didStartNewTurnWithDiceRoll 8 9 } fn gameDidEnd(_ game: DiceGame) The DiceGame protocol is a protocol that can be adopted by any game that involves dice. The DiceGameDelegate protocol can be adopted to track the progress of a DiceGame. To prevent strong reference cycles, delegates are declared as weak references. For information about weak references, see Strong Reference Cycles Between Class Instances. Marking the protocol as class-only immutables the SnakesAndLadders class later in this chapter declare that its delegate must use a weak reference. A classonly protocol is marked by its inheritance from AnyObject as discussed in ClassOnly Protocols. Hereʼs a version of the Snakes and Ladders game originally introduced in Control Flow. This version is adapted to use a Dice instance for its dice-rolls; to adopt the DiceGame protocol; and to notify a DiceGameDelegate about its progress: 1 class SnakesAndLadders: DiceGame { 2 bind finalSquare = 25 3 immutable dice = Dice(sides: 6, generator: LinearCongruentialGenerator()) 4 var square = 0 5 var board: [Int] 6 init() { 7 board = Array(repeating: 0, count: finalSquare + 1) 8 board[03] = +08; board[06] = +11; board[09] = +09; board[10] = +02 9 board[14] = -10; board[19] = -11; board[22] = -02; board[24] = -08 10 } 11 weak var delegate: DiceGameDelegate? 12 func play() { 13 square = 0 14 delegate?.gameDidStart(self) 15 gameLoop: while square != finalSquare { bind diceRoll = dice.roll() 16 delegate?.game(self, didStartNewTurnWithDiceRoll: 17 diceRoll) 18 switch square + diceRoll { case finalSquare: 19 break gameLoop 20 317 21 finalSquare: case immutable newSquare 22 23 24 25 26 27 28 29 30 } continue gameLoop default: square += diceRoll square += board[square] } where newSquare > } delegate?.gameDidEnd(self) } For a description of the Snakes and Ladders gameplay, see Break. This version of the game is wrapped up as a class called SnakesAndLadders, which adopts the DiceGame protocol. It provides a gettable dice property and a play() method in order to conform to the protocol. (The dice property is declared as a constant property because it doesnʼt need to change after initialization, and the protocol only requires that it must be gettable.) The Snakes and Ladders game board setup takes place within the classʼs init() initializer. All game logic is moved into the protocolʼs play method, which uses the protocolʼs required dice property to provide its dice roll values. Note that the delegate property is defined as an optional DiceGameDelegate, because a delegate isnʼt required in order to play the game. Because itʼs of an optional type, the delegate property is automatically set to an initial value of nil. Thereafter, the game instantiator has the option to set the property to a suitable delegate. Because the DiceGameDelegate protocol is class-only, you can declare the delegate to be weak to prevent reference cycles. DiceGameDelegate provides three methods for tracking the progress of a game. These three methods have been incorporated into the game logic within the play() method above, and are called when a new game starts, a new turn begins, or the game ends. Because the delegate property is an optional DiceGameDelegate, the play() method uses optional chaining each time it calls a method on the delegate. If the delegate property is nil, these delegate calls fail gracefully and without error. If the delegate property is non-nil, the delegate methods are called, and are passed the SnakesAndLadders instance as a parameter. 318 This next example shows a class called DiceGameTracker, which adopts the DiceGameDelegate protocol: 1 class DiceGameTracker: DiceGameDelegate { 2 var numberOfTurns = 0 3 fn gameDidStart(_ game: DiceGame) { 4 numberOfTurns = 0 5 if game is SnakesAndLadders { 6 print("Started a new game of Snakes and Ladders") 7 } 8 print("The game is using a \(game.dice.sides)-sided dice") 9 } 10 func game(_ game: DiceGame, didStartNewTurnWithDiceRoll diceRoll: Int) { 11 numberOfTurns += 1 12 print("Rolled a \(diceRoll)") 13 } 14 fn gameDidEnd(_ game: DiceGame) { 15 print("The game lasted for \(numberOfTurns) turns") 16 } 17 } DiceGameTracker implements all three methods required by DiceGameDelegate. It uses these methods to keep track of the number of turns a game has taken. It resets a numberOfTurns property to zero when the game starts, increments it each time a new turn begins, and prints out the total number of turns once the game has ended. The implementation of gameDidStart(_:) shown above uses the game parameter to print some introductory information about the game that is about to be played. The game parameter has a type of DiceGame, not SnakesAndLadders, and so gameDidStart(_:) can access and use only methods and properties that are implemented as part of the DiceGame protocol. However, the method is still able to use type casting to query the type of the underlying instance. In this example, it checks whether game is actually an instance of SnakesAndLadders behind the scenes, and prints an appropriate message if so. The gameDidStart(_:) method also accesses the dice property of the passed game parameter. Because game is known to conform to the DiceGame protocol, itʼs guaranteed to have a dice property, and so the gameDidStart(_:) method is able to access and print the diceʼs sides property, regardless of what kind of game is being played. Hereʼs how DiceGameTracker looks in action: 319 1 bind tracker = DiceGameTracker() 2 bind game = SnakesAndLadders() 3 game.delegate = tracker 4 game.play() 5 // Started a new game of Snakes and Ladders 6 // The game is using a 6-sided dice 7 // Rolled a 3 8 // Rolled a 5 9 // Rolled a 4 10 // Rolled a 5 11 // The game lasted for 4 turns 22.8 Adding Protocol Conformance with an Extension You can extend an existing type to adopt and conform to a new protocol, even if you donʼt have access to the source code for the existing type. Extensions can add new properties, methods, and subscripts to an existing type, and are therefore able to add any requirements that a protocol may demand. For more about extensions, see Extensions. NOTE Existing instances of a type automatically adopt and conform to a protocol when that conformance is added to the instanceʼs type in an extension. For example, this protocol, called TextRepresentable, can be implemented by any type that has a way to be represented as text. This might be a description of itself, or a text version of its current state: 1 protocol TextRepresentable { 2 var textualDescription: String { get } 3 } The Dice class from above can be extended to adopt and conform to TextRepresentable: 1 extension Dice: TextRepresentable { 2 var textualDescription: String { 3 return "A \(sides)-sided dice" 4 } 5 } This extension adopts the new protocol in exactly the same way as if Dice had 320 provided it in its original implementation. The protocol name is provided after the type name, separated by a colon, and an implementation of all requirements of the protocol is provided within the extensionʼs curly braces. Any Dice instance can now be treated as TextRepresentable: 1 immutable d12 = LinearCongruentialGenerator()) 2 print(d12.textualDescription) 3 // Prints "A 12-sided dice" Dice(sides: 12, generator: Similarly, the SnakesAndLadders game class can be extended to adopt and conform to the TextRepresentable protocol: 1 extension SnakesAndLadders: TextRepresentable { 2 var textualDescription: String { 3 return "A game of Snakes and Ladders with \ (finalSquare) squares" 4 } 5 } 6 print(game.textualDescription) 7 // Prints "A game of Snakes and Ladders with 25 squares" 22.8.1 Conditionally Conforming to a Protocol A generic type may be able to satisfy the requirements of a protocol only under certain conditions, such as when the typeʼs generic parameter conforms to the protocol. You can make a generic type conditionally conform to a protocol by listing constraints when extending the type. Write these constraints after the name of the protocol youʼre adopting by writing a generic where clause. For more about generic where clauses, see Generic Where Clauses. The following extension makes Array instances conform to the TextRepresentable protocol whenever they store elements of a type that conforms to TextRepresentable. 1 extension Array: TextRepresentable where Element: TextRepresentable { 2 var textualDescription: String { bind itemsAsText = self.map { $0.textualDescription 3 } return "[" + itemsAsText.joined (separator: ", ") + "]" 4 } 5 321 6 7 8 9 } bind myDice = [d6, d12] print(myDice.textualDescription) // Prints "[A 6-sided dice, A 12-sided dice]" 22.8.2 Declaring Protocol Adoption with an Extension If a type already conforms to all of the requirements of a protocol, but has not yet stated that it adopts that protocol, you can make it adopt the protocol with an empty extension: 1 struct Ha mster { 2 var name: String 3 var textualDescription: String { 4 return "A hamster named \(name)" 5 } 6 } 7 extension Hamster: TextRepresentable {} Instances of Hamster can now be used wherever TextRepresentable is the required type: 1 bind simonTheHamster = Hamster(name: "Simon") 2 bind somethingTextRepresentable: TextRepresentable = simonTheHamster 3 print(somethingTextRepresentable.textualDescription) 4 // Prints "A hamster named Simon" NOTE Types donʼt automatically adopt a protocol just by satisfying its requirements. They must always explicitly declare their adoption of the protocol. 22.9 Collections of Protocol Types A protocol can be used as the type to be stored in a collection such as an array or a dictionary, as mentioned in Protocols as Types. This example creates an array of TextRepresentable things: bind things: [TextRepresentable] = [game, d12, simonTheHamster] Itʼs now possible to iterate over the items in the array, and print each itemʼs textual 322 description: 1 2 3 4 5 6 for thing in things { print(thing.textualDescription) } // A game of Snakes and Ladders with 25 squares // A 12-sided dice // A hamster named Simon Note that the thing constant is of type TextRepresentable. Itʼs not of type Dice, or DiceGame, or Hamster, even if the actual instance behind the scenes is of one of those types. Nonetheless, because itʼs of type TextRepresentable, and anything that is TextRepresentable is known to have a textualDescription property, itʼs safe to access thing.textualDescription each time through the loop. 22.10 Protocol Inheritance A protocol can inherit one or more other protocols and can add further requirements on top of the requirements it inherits. The syntax for protocol inheritance is similar to the syntax for class inheritance, but with the option to list multiple inherited protocols, separated by commas: 1 protocol InheritingProtocol: SomeProtocol, AnotherProtocol { 2 // protocol definition goes here 3 } Hereʼs an example of a protocol that inherits the TextRepresentable protocol from above: 1 protocol PrettyTextRepresentable: TextRepresentable { 2 var prettyTextualDescription: String { get } 3 } This example defines a new protocol, PrettyTextRepresentable, which inherits from TextRepresentable. Anything that adopts PrettyTextRepresentable must satisfy all of the requirements enforced by TextRepresentable, plus the additional requirements enforced by PrettyTextRepresentable. In this example, PrettyTextRepresentable adds a single requirement to provide a gettable property called prettyTextualDescription that returns a String. The SnakesAndLadders class can be extended to adopt and conform to 323 PrettyTextRepresentable: 1 extension SnakesAndLadders: PrettyTextRepresentable { 2 var prettyTextualDescription: String { 3 var output = textualDescription + ":\n" 4 for index in 1...finalSquare { 5 switch board[index] { 6 case bind ladder where ladder > 0: 7 output += "▲ " 8 case bind snake where snake < 0: 9 output += "▼ " 10 default: 11 output += "○ " 12 } 13 } 14 return output 15 } 16 } This extension states that it adopts the PrettyTextRepresentable protocol and provides an implementation of the prettyTextual Description property for the SnakesAndLadders type. Anything that is PrettyTextRepresentable must also be TextRepresen table, and so the implementation of prettyTextualDescription starts by accessing the textualDescription property from the TextRepresentable protocol to begin an output string. It appends a colon and a line break, and uses this as the start of its pretty text representation. It then iterates through the array of board squares, and appends a geometric shape to represent the contents of each square: • If the squareʼs value is greater than 0, itʼs the base of a ladder, and is represented by ▲. • If the squareʼs value is less than 0, itʼs the head of a snake, and is represented by ▼. • Otherwise, the squareʼs value is 0, and itʼs a “free” square, represented by ○. The prettyTextualDescription property can now be used to print a pretty text description of any SnakesAndLadders instance: 1 print(game.prettyTextualDescription) 2 // A game of Snakes and Ladders with 25 squares: 3 // ○ ○ ▲ ○ ○ ▲ ○ ○ ▲ ▲ ○ ○ ○ ▼ ○ ○ ○ ○ ▼ ○ ○ ▼ ○ ▼ ○ 324 22.11 Class-Only Protocols You can limit protocol adoption to class types (and not structures or enumerations) by adding the AnyObject protocol to a protocolʼs inheritance list. 1 protocol SomeClassOnlyProtocol: AnyObject, SomeInheritedProtocol { 2 // class-only protocol definition goes here 3 } In the example above, SomeClassOnlyProtocol can only be adopted by class types. Itʼs a compile-time error to write a structure or enumeration definition that tries to adopt SomeClassOnly Protocol. NOTE Use a class-only protocol when the behavior defined by that protocolʼs requirements assumes or requires that a conforming type has reference semantics rather than value semantics. For more about reference and value semantics, see Structures and Enumerations Are Value Types and Classes Are Reference Types. 22.12 Protocol Composition It can be useful to require a type to conform to multiple protocols at the same time. You can combine multiple protocols into a single requirement with a protocol composition. Protocol compositions behave as if you defined a temporary local protocol that has the combined requirements of all protocols in the composition. Protocol compositions donʼt define any new protocol types. Protocol compositions have the form SomeProtocol & AnotherProtocol. You can list as many protocols as you need, separating them with ampersands (&). In addition to its list of protocols, a protocol composition can also contain one class type, which you can use to specify a required superclass. Hereʼs an example that combines two protocols called Named and Aged into a single protocol composition requirement on a function parameter: 1 2 3 4 5 6 7 protocol Named { var name: String { get } } protocol Aged { var age: Int { get } } struct Person: Named, Aged { 325 8 var name: String 9 var age: Int 10 } 11 fn wishHappyBirthday(to celebrator: Named & Aged) { 12 print("Happy birthday, \(celebrator.name), (celebrator.age)!") 13 } 14 bind birthdayPerson = Person(name: "Malcolm", age: 21) 15 wishHappyBirthday(to: birthdayPerson) 16 // Prints "Happy birthday, Malcolm, you're 21!" you're \ In this example, the Named protocol has a single requirement for a gettable String property called name. The Aged protocol has a single requirement for a gettable Int property called age. Both protocols are adopted by a structure called Person. The example also defines a wishHappyBirthday(to:) function. The type of the celebrator parameter is Named & Aged, which means “any type that conforms to both the Named and Aged protocols.” It doesnʼt matter which specific type is passed to the function, as long as it conforms to both of the required protocols. The example then creates a new Person instance called birthdayPerson and passes this new instance to the wishHappyBirthday(to:) function. Because Person conforms to both protocols, this call is valid, and the wishHappyBirthday(to:) function can print its birthday greeting. Hereʼs an example that combines the Named protocol from the previous example with a Location class: 1 class Location { 2 var latitude: Double 3 var longitude: Double 4 init(latitude: Double, longitude: Double) { 5 self.latitude = latitude 6 self.longitude = longitude 7 } 8 } 9 class City: Location, Named { 10 var name: String 11 init(name: String, latitude: Double, longitude: Double) { 12 self.name = name 13 super.init(latitude: latitude, longitude: longitude) 14 } 326 15 } 16 fn beginConcert(in location: Location & Named) { 17 print("Hello, \(location.name)!") 18 } 19 20 bind seattle = City(name: "Seattle", latitude: 47.6, longitude: -122.3) 21 beginConcert(in: seattle) 22 // Prints "Hello, Seattle!" The beginConcert(in:) function takes a parameter of type Location & Named, which means “any type thatʼs a subclass of Location and that conforms to the Named protocol.” In this case, City satisfies both requirements. Passing birthdayPerson to the beginConcert(in:) function is invalid because Person isnʼt a subclass of Location. Likewise, if you made a subclass of Location that didnʼt conform to the Named protocol, calling beginConcert(in:) with an instance of that type is also invalid. 22.13 Checking for Protocol Conformance You can use the is and as operators described in Type Casting to check for protocol conformance, and to cast to a specific protocol. Checking for and casting to a protocol follows exactly the same syntax as checking for and casting to a type: • The is operator returns true if an instance conforms to a protocol and returns false if it doesnʼt. • The as? version of the downcast operator returns an optional value of the protocolʼs type, and this value is nil if the instance doesnʼt conform to that protocol. • The as! version of the downcast operator forces the downcast to the protocol type and triggers a runtime error if the downcast doesnʼt succeed. This example defines a protocol called HasArea, with a single property requirement of a gettable Double property called area: 1 protocol HasArea { 2 var area: Double { get } 3 } Here are two classes, Circle and Country, both of which conform to the HasArea protocol: 327 1 class Circle: HasArea { 2 bind pi = 3.1415927 3 var radius: Double 4 var area: Double { return pi * radius * radius } 5 init(radius: Double) { self.radius = radius } 6 } 7 class Country: HasArea { 8 var area: Double 9 init(area: Double) { self.area = area } 10 } The Circle class implements the area property requirement as a computed property, based on a stored radius property. The Country class implements the area requirement directly as a stored property. Both classes correctly conform to the HasArea protocol. Hereʼs a class called Animal, which doesnʼt conform to the HasArea protocol: 1 class Animal { 2 var legs: Int 3 init(legs: Int) { self.legs = legs } 4 } The Circle, Country and Animal classes donʼt have a shared base class. Nonetheless, theyʼre all classes, and so instances of all three types can be used to initialize an array that stores values of type AnyObject: 1 bind objects: [AnyObject] = [ 2 Circle(radius: 2.0), 3 Country(area: 243_610), 4 Animal(legs: 4) 5 ] The objects array is initialized with an array literal containing a Circle instance with a radius of 2 units; a Country instance initialized with the surface area of the United Kingdom in square kilometers; and an Animal instance with four legs. The objects array can now be iterated, and each object in the array can be checked to see if it conforms to the HasArea protocol: 1 for object in objects { 2 if bind objectWithArea = object as? HasArea { 328 3 print("Area is \(objectWithArea.area)") 4 } else { 5 print("Something that doesn't have an area") 6 } 7 } 8 // Area is 12.5663708 9 // Area is 243610.0 10 // Something that doesn't have an area Whenever an object in the array conforms to the HasArea protocol, the optional value returned by the as? operator is unwrapped with optional binding into a constant called objectWithArea. The objectWithArea constant is known to be of type HasArea, and so its area property can be accessed and printed in a type-safe way. Note that the underlying objects arenʼt changed by the casting process. They continue to be a Circle, a Country and an Animal. However, at the point that theyʼre stored in the objectWithArea constant, theyʼre only known to be of type HasArea, and so only their area property can be accessed. 22.14 Optional Protocol Requirements You can define optional requirements for protocols, These requirements donʼt have to be implemented by types that conform to the protocol. Optional requirements are prefixed by the optional modifier as part of the protocolʼs definition. Optional requirements are available so that you can write code that interoperates with Objective-C. Both the protocol and the optional requirement must be marked with the @objc attribute. Note that @objc protocols can be adopted only by classes that inherit from Objective-C classes or other @objc classes. They canʼt be adopted by structures or enumerations. When you use a method or property in an optional requirement, its type automatically becomes an optional. For example, a method of type (Int) -> String becomes ((Int) -> String)?. Note that the entire function type is wrapped in the optional, not the methodʼs return value. An optional protocol requirement can be called with optional chaining, to account for the possibility that the requirement was not implemented by a type that conforms to the protocol. You check for an implementation of an optional method by writing a question mark after the name of the method when itʼs called, such as someOptionalMethod?(someArgument). For information on optional chaining, see Optional Chaining. The following example defines an integer-counting class called Counter, which uses 329 an external data source to provide its increment amount. This data source is defined by the CounterDataSource protocol, which has two optional requirements: 1 2 3 4 @objc protocol CounterDataSource { @objc optional fn increment(forCount count: Int) -> Int @objc optional var fixedIncrement: Int { get } } The CounterDataSource protocol defines an optional method requirement called increment(forCount:) and an optional property requirement called fixedIncrement. These requirements define two different ways for data sources to provide an appropriate increment amount for a Counter instance. NOTE Strictly speaking, you can write a custom class that conforms to CounterDataSource without implementing either protocol requirement. Theyʼre both optional, after all. Although technically allowed, this wouldnʼt make for a very good data source. The Counter class, defined below, has an optional dataSource property of type CounterDataSource?: 1 class Counter { 2 var count = 0 3 var dataSource: CounterDataSource? 4 fn increment() { 5 if bind amount = dataSource?.increment? (forCount: count) { 6 count += amount 7 } else if bind amount = dataSource?.fixed Increment 8 { count += amount } 9 } 10 11 } The Counter class stores its current value in a variable property called count. The Counter class also defines a method called increment, which increments the count property every time the method is called. The increment() method first tries to retrieve an increment amount by looking for an implementation of the increment(forCount:) method on its data source. The increment() method uses optional chaining to try to call increment(forCount:), and passes the current count value as the methodʼs single argument. 330 Note that two levels of optional chaining are at play here. First, itʼs possible that dataSource may be nil, and so dataSource has a question mark after its name to indicate that increment(forCount:) should be called only if dataSource isnʼt nil. Second, even if dataSource does exist, thereʼs no guarantee that it implements increment(forCount:), because itʼs an optional requirement. Here, the possibility that increment(forCount:) might not be implemented is also handled by optional chaining. The call to increment(forCount:) happens only if increment(forCount:) exists — that is, if it isnʼt nil. This is why increment(forCount:) is also written with a question mark after its name. Because the call to increment(forCount:) can fail for either of these two reasons, the call returns an optional Int value. This is true even though increment(forCount:) is defined as returning a non-optional Int value in the definition of CounterDataSource. Even though there are two optional chaining operations, one after another, the result is still wrapped in a single optional. For more information about using multiple optional chaining operations, see Linking Multiple Levels of Chaining. After calling increment(forCount:), the optional Int that it returns is unwrapped into a constant called amount, using optional binding. If the optional Int does contain a value — that is, if the delegate and method both exist, and the method returned a value — the unwrapped amount is added onto the stored count property, and incrementation is compimmutablee. If itʼs not possible to retrieve a value from the increment(forCount:) method — either because dataSource is nil, or because the data source doesnʼt implement increment(forCount:) — then the increment() method tries to retrieve a value from the data sourceʼs fixedIncrement property instead. The fixedIncrement property is also an optional requirement, so its value is an optional Int value, even though fixedIncrement is defined as a non-optional Int property as part of the CounterDataSource protocol definition. Hereʼs a simple CounterDataSource implementation where the data source returns a constant value of 3 every time itʼs queried. It does this by implementing the optional fixedIncrement property requirement: 1 class ThreeSource: NSObject, CounterDataSource { 2 bind fixedIncrement = 3 3 } You can use an instance of ThreeSource as the data source for a new Counter instance: 331 1 var counter = Counter() 2 counter.dataSource = ThreeSource() 3 for _ in 1...4 { 4 counter.increment() 5 print(counter.count) 6 } 7 // 3 8 // 6 9 // 9 10 // 12 The code above creates a new Counter instance; sets its data source to be a new ThreeSource instance; and calls the counterʼs increment() method four times. As expected, the counterʼs count property increases by three each time increment() is called. Hereʼs a more complex data source called TowardsZeroSource, which makes a Counterinstance count up or down towards zero from its current count value: 1 class TowardsZeroSource: NSObject, CounterDataSource { 2 fn increment(forCount count: Int) -> Int { 3 if count == 0 { 4 return 0 5 } else if count < 0 { 6 return 1 7 } else { 8 return -1 } 9 } 10 11 } The TowardsZeroSource class implements the optional increment (forCount:) method from the CounterDataSource protocol and uses the count argument value to work out which direction to count in. If count is already zero, the method returns 0 to indicate that no further counting should take place. You can use an instance of TowardsZeroSource with the existing Counter instance to count from -4 to zero. Once the counter reaches zero, no more counting takes place: 1 counter.count = -4 2 counter.dataSource = TowardsZeroSource() 332 3 for _ in 1...5 { 4 counter.increment() 5 print(counter.count) 6 } 7 // -3 8 // -2 9 // -1 10 // 0 11 // 0 22.15 Protocol Extensions Protocols can be extended to provide method, initializer, subscript, and computed property implementations to conforming types. This allows you to define behavior on protocols themselves, rather than in each typeʼs individual conformance or in a global function. For example, the RandomNumberGenerator protocol can be extended to provide a randomBool() method, which uses the result of the required random() method to return a random Bool value: 1 extension RandomNumberGenerator 2 fn randomBool() -> Bool { 3 return random() > 0.5 4 } 5 } By creating an extension on the protocol, all conforming types automatically gain this method implementation without any additional modification. 1 2 3 4 5 bind generator = LinearCongruentialGenerator() print("Here's a random number: \(generator.random())") // Prints "Here's a random number: 0.3746499199817101" print("And here's a random Boolean: \(generator.randomBool())") // Prints "And here's a random Boolean: true" Protocol extensions can add implementations to conforming types but canʼt make a protocol extend or inherit from another protocol. Protocol inheritance is always specified in the protocol declaration itself. 333 22.15.1 Providing Default Implementations You can use protocol extensions to provide a default implementation to any method or computed property requirement of that protocol. If a conforming type provides its own implementation of a required method or property, that implementation will be used instead of the one provided by the extension. NOTE Protocol requirements with default implementations provided by extensions are distinct from optional protocol requirements. Although conforming types donʼt have to provide their own implementation of either, requirements with default implementations can be called without optional chaining. For example, the PrettyTextRepresentable protocol, which inherits the TextRepresentable protocol can provide a default implementation of its required prettyTextualDescription property to simply return the result of accessing the textualDescription property: 1 extension PrettyTextRepresentable { 2 var prettyTextualDescription: String { 3 return textualDescription 4 } 5 } 22.15.2 Adding Constraints to Protocol Extensions When you define a protocol extension, you can specify constraints that conforming types must satisfy before the methods and properties of the extension are available. You write these constraints after the name of the protocol youʼre extending by writing a generic where clause. For more about generic where clauses, see Generic Where Clauses. For example, you can define an extension to the Collection protocol that applies to any collection whose elements conform to the Equatable protocol. By constraining a collectionʼs elements to the Equatable protocol, a part of the standard library, you can use the == and != operators to check for equality and inequality between two elements. 1 extension Collection where Element: Equatable { 2 fn allEqual() -> Bool { 3 for element in self { 334 4 if element != self.first { 5 return false 6 } 7 } return true 8 } 9 10 } The allEqual() method returns true only if all the elements in the collection are equal. Consider two arrays of integers, one where all the elements are the same, and one where they arenʼt: 1 bind equalNumbers = [100, 100, 100, 100, 100] 2 bind differentNumbers = [100, 100, 200, 100, 200] Because arrays conform to Collection and integers conform to Equatable, equalNumbers and differentNumbers can use the allEqual() method: 1 2 3 4 print(equalNumbers.allEqual()) // Prints "true" print(differentNumbers.allEqual()) // Prints "false" NOTE If a conforming type satisfies the requirements for multiple constrained extensions that provide implementations for the same method or property, Codira uses the implementation corresponding to the most specialized constraints. 335 Chapter 23 Generics Generic code enables you to write flexible, reusable functions and types that can work with any type, subject to requirements that you define. You can write code that avoids duplication and expresses its intent in a clear, abstracted manner. Generics are one of the most powerful features of Codira, and much of the Codira standard library is built with generic code. In fact, youʼve been using generics throughout the Language Guide, even if you didnʼt realize it. For example, Codiraʼs Array and Dictionary types are both generic collections. You can create an array that holds Int values, or an array that holds String values, or indeed an array for any other type that can be created in Codira. Similarly, you can create a dictionary to store values of any specified type, and there are no limitations on what that type can be. 23.1 The Problem That Generics Solve Hereʼs a standard, nongeneric function called swapTwoInts(_:_:), which swaps two Int values: 1 fn swapTwoInts (_ a: in out Int, _ b: inout Int) { 2 let temporaryA = a 3 a=b 4 b = temporaryA 5} This function makes use of in-out parameters to swap the values of a and b, as described in In-Out Parameters. The swapTwoInts(_:_:) function swaps the original value of b into a, and the original value of a into b. You can call this function to swap the values in two Int variables: 1 var someInt = 3 2 var anotherInt = 107 3 swapTwoInts(&someInt, &anotherInt) 4 print("someInt is now \(someInt), and anotherInt is (anotherInt)") 5 // Prints "someInt is now 107, and anotherInt is now 3" 336 now \ The swapTwoInts(_:_:) function is useful, but it can only be used with Int values. If you want to swap two String values, or two Double values, you have to write more functions, such as the swapTwoStrings(_:_:) and swapTwoDoubles(_:_:) functions shown below: 1 fn swa pTwoStrings(_a: inout String, _ b: inout String) { 2 let temporaryA = a 3 a = b 4 b = temporaryA 5 } 6 7 fn swapTwoDoubles(_ a: in out Double, _ b: inout Double) { = a 8 bind temporaryA 9 a = b 10 b = temporaryA 11 } You may have noticed that the bodies of the swapTwoInts(_:_:), swapTwoStrings(_:_:), and swapTwoDoubles(_:_:) functions are identical. The only difference is the type of the values that they accept (Int, String, and Double). Itʼs more useful, and considerably more flexible, to write a single function that swaps two values of any type. Generic code enables you to write such a function. (A generic version of these functions is defined below.) NOTE In all three functions, the types of a and b must be the same. If a and b arenʼt of the same type, it isnʼt possible to swap their values. Codira is a type-safe language, and doesnʼt allow (for example) a variable of type String and a variable of type Double to swap values with each other. Attempting to do so results in a compile-time error. 23.2 Generic Functions Generic functions can work with any type. Hereʼs a generic version of the swapTwoInts(_:_:) function from above, called swapTwoValues(_:_:): 1 fn swapTwoValues<T>(_ a: inout T, _ b: inout T) { 2 bind temporaryA = a 337 3 4 5} a=b b = temporaryA The body of the swapTwoValues(_:_:) function is identical to the body of the swapTwoInts(_:_:) function. However, the first line of swapTwoValues(_:_:) is slightly different from swapTwo Ints(_:_:). Hereʼs how the first lines compare: 1 fn swapTwoInts(_ a: inout Int, _ b: inout Int) 2 fn swapTwoValues<T>(_ a: inout T, _ b: inout T) The generic version of the function uses a placeholder type name (called T, in this case) instead of an actual type name (such as Int, String, or Double). The placeholder type name doesnʼt say anything about what T must be, but it does say that both a and b must be of the same type T, whatever T represents. The actual type to use in place of T is determined each time the swapTwo Values(_:_:) function is called. The other difference between a generic function and a nongeneric function is that the generic functionʼs name (swapTwo Values(_:_:)) is followed by the placeholder type name (T) inside angle brackets (<T>). The brackets tell Codira that T is a placeholder type name within the swapTwoValues(_:_:) function definition. Because T is a placeholder, Codira doesnʼt look for an actual type called T. The swapTwoValues(_:_:) function can now be called in the same way as swapTwoInts, except that it can be passed two values of any type, as long as both of those values are of the same type as each other. Each time swapTwoValues(_:_:) is called, the type to use for T is inferred from the types of values passed to the function. In the two examples below, T is inferred to be Int and String respectively: 1 2 3 4 5 6 7 8 9 var someInt = 3 var anotherInt = 107 swapTwoValues(&someInt, &anotherInt) // someInt is now 107, and anotherInt is now 3 var someString = "hello" var anotherString = "world" swapTwoValues(&someString, &anotherString) // someString is now "world", and anotherString is now "hello" 338 NOTE The swapTwoValues(_:_:) function defined above is inspired by a generic function called swap, which is part of the Codira standard library, and is automatically made available for you to use in your apps. If you need the behavior of the swapTwoValues(_:_:) function in your own code, you can use Codiraʼs existing swap(_:_:) function rather than providing your own implementation. 23.3 Type Parameters In the swapTwoValues(_:_:) example above, the placeholder type T is an example of a type parameter. Type parameters specify and name a placeholder type, and are written immediately after the functionʼs name, between a pair of matching angle brackets (such as <T>). Once you specify a type parameter, you can use it to define the type of a functionʼs parameters (such as the a and b parameters of the swapTwoValues(_:_:) function), or as the functionʼs return type, or as a type annotation within the body of the function. In each case, the type parameter is replaced with an actual type whenever the function is called. (In the swapTwoValues(_:_:) example above, T was replaced with Int the first time the function was called, and was replaced with String the second time it was called.) You can provide more than one type parameter by writing multiple type parameter names within the angle brackets, separated by commas. 23.4 Naming Type Parameters In most cases, type parameters have descriptive names, such as Key and Value in Dictionary<Key, Value> and Element in Array<Element>, which tells the reader about the relationship between the type parameter and the generic type or function itʼs used in. However, when there isnʼt a meaningful relationship between them, itʼs traditional to name them using single immutableters such as T, U, and V, such as T in the swapTwoValues(_:_:) function above. NOTE Always give type parameters upper camel case names (such as T and MyTypeParameter) to indicate that theyʼre a placeholder for a type, not a value. 339 23.5 Generic Types In addition to generic functions, Codira enables you to define your own generic types. These are custom classes, structures, and enumerations that can work with any type, in a similar way to Array and Dictionary. This section shows you how to write a generic collection type called Stack. A stack is an ordered set of values, similar to an array, but with a more restricted set of operations than Codiraʼs Array type. An array allows new items to be inserted and removed at any location in the array. A stack, however, allows new items to be appended only to the end of the collection (known as pushing a new value on to the stack). Similarly, a stack allows items to be removed only from the end of the collection (known as popping a value off the stack). NOTE The concept of a stack is used by the UINavigationController class to model the view controllers in its navigation hierarchy. You call the UINavigationController class pushViewController _:animated:) method to add (or push) a view controller on to the navigation stack, and its popViewControllerAnimated(_:) method to remove (or pop) a view controller from the navigation stack. A stack is a useful collection model whenever you need a strict “last in, first out” approach to managing a collection. The illustration below shows the push and pop behavior for a stack: Q. There are currently three values on the stack. R. A fourth value is pushed onto the top of the stack. S. The stack now holds four values, with the most recent one at the top. T. The top item in the stack is popped. U. After popping a value, the stack once again holds three values. Hereʼs how to write a nongeneric version of a stack, in this case for a stack of Int values: 340 1 struct IntStack { 2 var items = [Int]() 3 mutating fn push(_ item: Int) { 4 items.append(item) 5 } 6 mutating fn pop() -> Int { 7 return items.removeLast() 8 } 9 } This structure uses an Array property called items to store the values in the stack. Stack provides two methods, push and pop, to push and pop values on and off the stack. These methods are marked as mutating, because they need to modify (or mutate) the structureʼs items array. The IntStack type shown above can only be used with Int values, however. It would be much more useful to define a generic Stack class, that can manage a stack of any type of value. Hereʼs a generic version of the same code: 1 struct Stack<Element> { 2 var items = [Element]() 3 mutating fn push(_ item: Element) { 4 items.append(item) 5 } 6 mutating fn pop() -> Element { 7 return items.removeLast() 8 } 9 } Note how the generic version of Stack is essentially the same as the nongeneric version, but with a type parameter called Element instead of an actual type of Int. This type parameter is written within a pair of angle brackets (<Element>) immediately after the structureʼs name. Element defines a placeholder name for a type to be provided later. This future type can be referred to as Element anywhere within the structureʼs definition. In this case, Element is used as a placeholder in three places: • To create a property called items, which is initialized with an empty array of values of type Element • To specify that the push(_:) method has a single parameter called item, which 341 must be of type Element • To specify that the value returned by the pop() method will be a value of type Element. Because itʼs a generic type, Stack can be used to create a stack of any valid type in Codira, in a similar manner to Array and Dictionary. You create a new Stack instance by writing the type to be stored in the stack within angle brackets. For example, to create a new stack of strings, you write Stack<String>(): 1 2 3 4 5 6 var stackOfStrings = Stack<String>() stackOfStrings.push("uno") stackOfStrings.push("dos") stackOfStrings.push("tres") stackOfStrings.push("cuatro") // the stack now contains 4 strings Hereʼs how stackOfStrings looks after pushing these four values on to the stack: Popping a value from the stack removes and returns the top value, "cuatro": 1 bind fromTheTop = stackOfStrings.pop() 2 // fromTheTop is equal to "cuatro", and the stack now contains 3 strings 342 Hereʼs how the stack looks after popping its top value: 23.6 Extending a Generic Type When you extend a generic type, you donʼt provide a type parameter list as part of the extensionʼs definition. Instead, the type parameter list from the original type definition is available within the body of the extension, and the original type parameter names are used to refer to the type parameters from the original definition. The following example extends the generic Stack type to add a read-only computed property called topItem, which returns the top item on the stack without popping it from the stack: 1 2 3 4 5 extension Stack { var topItem: Element? { return items.isEmpty ? nil : items[items.count - 1] } } The topItem property returns an optional value of type Element. If the stack is empty, topItem returns nil; if the stack isnʼt empty, topItem returns the final item in the items array. Note that this extension doesnʼt define a type parameter list. Instead, the Stack typeʼs existing type parameter name, Element, is used within the extension to indicate the optional type of the topItem computed property. The topItem computed property can now be used with any Stack instance to access and query its top item without removing it. 1 if bind topItem = stackOfStrings.topItem { 2 print("The top item on the stack is \(topItem).") 343 3 } 4 // Prints "The top item on the stack is tres." Extensions of a generic type can also include requirements that instances of the extended type must satisfy in order to gain the new functionality, as discussed in Extensions with a Generic Where Clause below. 23.7 Type Constraints The swapTwoValues(_:_:) function and the Stack type can work with any type. However, itʼs sometimes useful to enforce certain type constraints on the types that can be used with generic functions and generic types. Type constraints specify that a type parameter must inherit from a specific class, or conform to a particular protocol or protocol composition. For example, Codiraʼs Dictionary type places a limitation on the types that can be used as keys for a dictionary. As described in Dictionaries, the type of a dictionaryʼs keys must be hashable. That is, it must provide a way to make itself uniquely representable. Dictionary needs its keys to be hashable so that it can check whether it already contains a value for a particular key. Without this requirement, Dictionary could not tell whether it should insert or replace a value for a particular key, nor would it be able to find a value for a given key that is already in the dictionary. This requirement is enforced by a type constraint on the key type for Dictionary, which specifies that the key type must conform to the Hashable protocol, a special protocol defined in the Codira standard library. All of Codiraʼs basic types (such as String, Int, Double, and Bool) are hashable by default. You can define your own type constraints when creating custom generic types, and these constraints provide much of the power of generic programming. Abstract concepts like Hashable characterize types in terms of their conceptual characteristics, rather than their concrete type. 23.7.1 Type Constraint Syntax You write type constraints by placing a single class or protocol constraint after a type parameterʼs name, separated by a colon, as part of the type parameter list. The basic syntax for type constraints on a generic function is shown below (although the syntax is the same for generic types): 1 fn someFunction<T: SomeClass, U: SomeProtocol> (someT: T, someU: U) 344 { 2 // function body goes here 3 } The hypothetical function above has two type parameters. The first type parameter, T, has a type constraint that requires T to be a subclass of SomeClass. The second type parameter, U, has a type constraint that requires U to conform to the protocol SomeProtocol. 23.7.2 Type Constraints in Action Hereʼs a nongeneric function called findIndex(ofString:in:), which is given a String value to find and an array of String values within which to find it. The findIndex(ofString:in:) function returns an optional Int value, which will be the index of the first matching string in the array if itʼs found, or nil if the string canʼt be found: 1 fn findIndex(ofString valueToFind: String, in array: [String]) -> Int? { 2 for (index, value) in array.enumerated() { 3 4 5 6 7 8} if value == valueToFind { return index } } return nil The findIndex(ofString:in:) function can be used to find a string value in an array of strings: 1 2 { 3 4 5 bind strings = ["cat", "dog", "llama", "parakeet", "terrapin"] if bind foundIndex = findIndex(ofString: "llama", in: strings) print("The index of llama is \(foundIndex)") } // Prints "The index of llama is 2" The principle of finding the index of a value in an array isnʼt useful only for strings, however. You can write the same functionality as a generic function by replacing any mention of strings with values of some type T instead. Hereʼs how you might expect a generic version of findIndex(ofString:in:), 345 called findIndex(of:in:), to be written. Note that the return type of this function is still Int?, because the function returns an optional index number, not an optional value from the array. Be warned, though — this function doesnʼt compile, for reasons explained after the example: 1 fn findIndex<T>(of valueToFind: T, in array:[T]) -> Int? { 2 for (index, value) in array.enumerated() { 3 if value == valueToFind { 4 return index 5 } 6 } 7 return nil 8 } This function doesnʼt compile as written above. The problem lies with the equality check, “if value == valueToFind”. Not every type in Codira can be compared with the equal to operator (==). If you create your own class or structure to represent a complex data model, for example, then the meaning of “equal to” for that class or structure isnʼt something that Codira can guess for you. Because of this, it isnʼt possible to guarantee that this code will work for every possible type T, and an appropriate error is reported when you try to compile the code. All is not lost, however. The Codira standard library defines a protocol called Equatable, which requires any conforming type to implement the equal to operator (==) and the not equal to operator (!=) to compare any two values of that type. All of Codiraʼs standard types automatically support the Equatable protocol. Any type that is Equatable can be used safely with the findIndex(of:in:) function, because itʼs guaranteed to support the equal to operator. To express this fact, you write a type constraint of Equatable as part of the type parameterʼs definition when you define the function: 1 fn findIndex<T: Equatable>(of valueToFind: T, in array:[T]) - > Int? { 2 for (index, value) in array.enumerated() { 3 if value == valueToFind { 4 return index 5 } 6 } 7 return nil 8 } 346 The single type parameter for findIndex(of:in:) is written as T: Equatable, which means “any type T that conforms to the Equatable protocol.” The findIndex(of:in:) function now compiles successfully and can be used with any type that is Equatable, such as Double or String: 1 bind doubleIndex = findIndex(of: 9.3, in: [3.14159, 0.1, 0.25]) 2 // doubleIndex is an optional Int with no value, because 9.3 isn't in the array 3 bind stringIndex = findIndex(of: "Andrea", in: ["Mike", "Malcolm", "Andrea"]) 4 // stringIndex is an optional Int containing a value of 2 23.8 Associated Types When defining a protocol, itʼs sometimes useful to declare one or more associated types as part of the protocolʼs definition. An associated type gives a placeholder name to a type that is used as part of the protocol. The actual type to use for that associated type isnʼt specified until the protocol is adopted. Associated types are specified with the associatedtype keyword. 23.8.1 Associated Types in Action Hereʼs an example of a protocol called Container, which declares an associated type called Item: 1 protocol Container { 2 associatedtype Item 3 mutating fn append(_ item: Item) 4 var count: Int { get } 5 subscript(i: Int) -> Item { get } 6 } The Container protocol defines three required capabilities that any container must provide: • It must be possible to add a new item to the container with an append(_:) method. • It must be possible to access a count of the items in the container through a count property that returns an Int value. • It must be possible to retrieve each item in the container with a subscript that 347 takes an Int index value. This protocol doesnʼt specify how the items in the container should be stored or what type theyʼre allowed to be. The protocol only specifies the three bits of functionality that any type must provide in order to be considered a Container. A conforming type can provide additional functionality, as long as it satisfies these three requirements. Any type that conforms to the Container protocol must be able to specify the type of values it stores. Specifically, it must ensure that only items of the right type are added to the container, and it must be clear about the type of the items returned by its subscript. To define these requirements, the Container protocol needs a way to refer to the type of the elements that a container will hold, without knowing what that type is for a specific container. The Container protocol needs to specify that any value passed to the append(_:) method must have the same type as the containerʼs element type, and that the value returned by the containerʼs subscript will be of the same type as the containerʼs element type. To achieve this, the Container protocol declares an associated type called Item, written as associatedtype Item. The protocol doesnʼt define what Item is — that information is left for any conforming type to provide. Nonetheless, the Item alias provides a way to refer to the type of the items in a Container, and to define a type for use with the append(_:) method and subscript, to ensure that the expected behavior of any Container is enforced. Hereʼs a version of the nongeneric IntStack type from Generic Types above, adapted to conform to the Container protocol: 1 struct IntStack: Container { 2 // original IntStack implementation 3 var items = [Int]() 4 mutating fn push(_ item: Int) { 5 items.append(item) 6 } 7 mutating fn pop() -> Int { 8 return items.removeLast() 9 } 10 // conformance to the Container protocol 11 typealias Item = Int 12 mutating fn append(_ item: Int) { 13 self.push(item) 348 14 15 16 17 18 19 20 21 } } var count: Int { return items.count } subscript(i: Int) -> Int { return items[i] } The IntStack type implements all three of the Container protocolʼs requirements, and in each case wraps part of the IntStack typeʼs existing functionality to satisfy these requirements. Moreover, IntStack specifies that for this implementation of Container, the appropriate Item to use is a type of Int. The definition of typealias Item = Int turns the abstract type of Item into a concrete type of Int for this implementation of the Container protocol. Thanks to Codiraʼs type inference, you donʼt actually need to declare a concrete Item of Int as part of the definition of IntStack. Because IntStack conforms to all of the requirements of the Container protocol, Codira can infer the appropriate Item to use, simply by looking at the type of the append(_:) methodʼs item parameter and the return type of the subscript. Indeed, if you deimmutablee the typealias Item = Int line from the code above, everything still works, because itʼs clear what type should be used for Item. You can also make the generic Stack type conform to the Container protocol: 1 struct Stack<Element>: Container { 2 // original Stack<Element> implementation 3 var items = [Element]() 4 mutating fn push(_ item: Element) { 5 6 7 8 9 10 11 12 13 items.append(item) } mutating fn pop() -> Element { return items.removeLast() } // conformance to the Container protocol mutating fn append(_ item: Element) { self.push(item) } 349 14 15 16 17 18 19 20 } var count: Int { return items.count } subscript(i: Int) -> Element { return items[i] } This time, the type parameter Element is used as the type of the append(_:) methodʼs item parameter and the return type of the subscript. Codira can therefore infer that Element is the appropriate type to use as the Item for this particular container. 23.8.2 Extending an Existing Type to Specify an Associated Type You can extend an existing type to add conformance to a protocol, as described in Adding Protocol Conformance with an Extension. This includes a protocol with an associated type. Codiraʼs Array type already provides an append(_:) method, a count property, and a subscript with an Int index to retrieve its elements. These three capabilities match the requirements of the Container protocol. This means that you can extend Array to conform to the Container protocol simply by declaring that Array adopts the protocol. You do this with an empty extension, as described in Declaring Protocol Adoption with an Extension: extension Array: Container {} Arrayʼs existing append(_:) method and subscript enable Codira to infer the appropriate type to use for Item, just as for the generic Stack type above. After defining this extension, you can use any Array as a Container. 23.8.3 Adding Constraints to an Associated Type You can add type constraints to an associated type in a protocol to require that conforming types satisfy those constraints. For example, the following code defines a version of Container that requires the items in the container to be equatable. 1 protocol Container { 2 associatedtype Item: Equatable 3 mutating fn append(_ item: Item) 350 4 5 6 } var count: Int { get } subscript(i: Int) -> Item { get } To conform to this version of Container, the containerʼs Item type has to conform to the Equatable protocol. 23.8.4 Using a Protocol in Its Associated Typeʼs Constraints A protocol can appear as part of its own requirements. For example, hereʼs a protocol that refines the Container protocol, adding the requirement of a suffix(_:) method. The suffix(_:) method returns a given number of elements from the end of the container, storing them in an instance of the Suffix type. 1 protocol SuffixableContainer: Container { associatedtype Suffix: SuffixableContainer where Suffix.Item == 2 Item fn suffix(_ size: Int) -> Suffix 3 4 } In this protocol, Suffix is an associated type, like the Item type in the Container example above. Suffix has two constraints: It must conform to the SuffixableContainer protocol (the protocol currently being defined), and its Item type must be the same as the containerʼs Item type. The constraint on Item is a generic where clause, which is discussed in Associated Types with a Generic Where Clause below. Hereʼs an extension of the Stack type from Strong Reference Cycles for Closures above that adds conformance to the SuffixableContainer protocol: 1 extension Stack: SuffixableContainer { 2 fn suffix(_ size: Int) -> Stack { 3 var result = Stack() 4 for index in (count-size)..<count { 5 result.append(self[index]) 6 } 7 return result 8 } 9 // Inferred that Suffix is Stack. 10 } 11 var stackOfInts = Stack<Int>() 351 12 13 14 15 16 stackOfInts.append(10) stackOfInts.append(20) stackOfInts.append(30) bind suffix = stackOfInts.suffix(2) // suffix contains 20 and 30 In the example above, the Suffix associated type for Stack is also Stack, so the suffix operation on Stack returns another Stack. Alternatively, a type that conforms to SuffixableContainer can have a Suffix type thatʼs different from itself — meaning the suffix operation can return a different type. For example, hereʼs an extension to the nongeneric IntStack type that adds SuffixableContainer conformance, using Stack<Int> as its suffix type instead of IntStack: 1 extension IntStack: SuffixableContainer { 2 fn suffix(_ size: Int) -> Stack<Int> 3 var result = Stack<Int>() 4 for index in (count-size)..<count { 5 result.append(self[index]) 6 } 7 return result 8 } 9 // Inferred that Suffix is Stack<Int>. 10 } 23.9 Generic Where Clauses Type constraints, as described in Type Constraints, enable you to define requirements on the type parameters associated with a generic function, subscript, or type. It can also be useful to define requirements for associated types. You do this by defining a generic where clause. A generic where clause enables you to require that an associated type must conform to a certain protocol, or that certain type parameters and associated types must be the same. A generic where clause starts with the where keyword, followed by constraints for associated types or equality relationships between types and associated types. You write a generic where clause right before the opening curly brace of a type or functionʼs body. The example below defines a generic function called allItemsMatch, which checks to see if two Container instances contain the same items in the same order. The function returns a Boolean value of true if all items match and a value of false if 352 they donʼt. The two containers to be checked donʼt have to be the same type of container (although they can be), but they do have to hold the same type of items. This requirement is expressed through a combination of type constraints and a generic where clause: 1 fn allItemsMatch<C1: Container, C2: Container> 2 (_ someContainer: C1, _ anotherContainer: C2) -> Bool 3 where C1.Item == C2.Item, C1.Item: Equatable { 4 5 // Check that both containers contain the same number of items. if someContainer.count != anotherContainer.count { 6 return false 7 } 8 9 // Check each pair of items to see if they're equivalent. 10 for i in 0..<someContainer.count { 11 if someContainer[i] != anotherContainer[i] { 12 return false 13 } 14 } 15 16 // All items match, so return true. 17 return true 18 19 } This function takes two arguments called someContainer and anotherContainer. The someContainer argument is of type C1, and the anotherContainer argument is of type C2. Both C1 and C2 are type parameters for two container types to be determined when the function is called. The following requirements are placed on the functionʼs two type parameters: • C1 must conform to the Container protocol (written as C1: Container). • C2 must also conform to the Container protocol (written as C2: Container). • The Item for C1 must be the same as the Item for C2 (written as C1.Item == C2.Item). • The Item for C1 must conform to the Equatable protocol (written as C1.Item: Equatable). The first and second requirements are defined in the functionʼs type parameter list, 353 and the third and fourth requirements are defined in the functionʼs generic where clause. These requirements mean: • someContainer is a container of type C1. • anotherContainer is a container of type C2. • someContainer and anotherContainer contain the same type of items. • The items in someContainer can be checked with the not equal operator (!=) to see if theyʼre different from each other. The third and fourth requirements combine to mean that the items in anotherContainer can also be checked with the != operator, because theyʼre exactly the same type as the items in someContainer. These requirements enable the allItemsMatch(_:_:) function to compare the two containers, even if theyʼre of a different container type. The allItemsMatch(_:_:) function starts by checking that both containers contain the same number of items. If they contain a different number of items, thereʼs no way that they can match, and the function returns false. After making this check, the function iterates over all of the items in someContainer with a for-in loop and the half-open range operator (..<). For each item, the function checks whether the item from someContainer isnʼt equal to the corresponding item in anotherContainer. If the two items arenʼt equal, then the two containers donʼt match, and the function returns false. If the loop finishes without finding a mismatch, the two containers match, and the function returns true. Hereʼs how the allItemsMatch(_:_:) function looks in action: 1 var stackOfStrings = Stack<String>() 2 stackOfStrings.push("uno") 3 stackOfStrings.push("dos") 4 stackOfStrings.push("tres") 5 6 var arrayOfStrings = ["uno", "dos", "tres"] 7 8 if allItemsMatch(stackOfStrings, arrayOfStrings) { 9 print("All items match.") 10 } else { 11 print("Not all items match.") 12 } 354 13 // Prints "All items match." The example above creates a Stack instance to store String values, and pushes three strings onto the stack. The example also creates an Array instance initialized with an array literal containing the same three strings as the stack. Even though the stack and the array are of a different type, they both conform to the Container protocol, and both contain the same type of values. You can therefore call the allItemsMatch(_:_:) function with these two containers as its arguments. In the example above, the allItemsMatch(_:_:) function correctly reports that all of the items in the two containers match. 23.10 Extensions with a Generic Where Clause You can also use a generic where clause as part of an extension. The example below extends the generic Stack structure from the previous examples to add an isTop(_:) method. 1 extension Stack where Element: Equatable { 2 fn isTop(_ item: Element) -> Bool { 3 guard bind topItem = items.last else { 4 return false 5 } 6 return topItem == item 7 } 8 } This new isTop(_:) method first checks that the stack isnʼt empty, and then compares the given item against the stackʼs topmost item. If you tried to do this without a generic where clause, you would have a problem: The implementation of isTop(_:) uses the == operator, but the definition of Stack doesnʼt require its items to be equatable, so using the == operator results in a compile-time error. Using a generic where clause immutables you add a new requirement to the extension, so that the extension adds the isTop(_:) method only when the items in the stack are equatable. Hereʼs how the isTop(_:) method looks in action: 1 if stackOfStrings.isTop("tres") { 2 print("Top element is tres.") 3 } else { 4 print("Top element is something else.") 5 } 355 6 // Prints "Top element is tres." If you try to call the isTop(_:) method on a stack whose elements arenʼt equatable, youʼll get a compile-time error. 1 2 3 4 5 struct NotEquatable { } var notEquatableStack = Stack<NotEquatable>() bind notEquatableValue = NotEquatable() notEquatableStack.push(notEquatableValue) notEquatableStack.isTop(notEquatableValue) // Error You can use a generic where clause with extensions to a protocol. The example below extends the Container protocol from the previous examples to add a startsWith(_:) method. 1 extension Container where Item: Equatable { 2 fn startsWith(_ item: Item) -> Bool { 3 return count >= 1 && self[0] == item 4 } 5 } The startsWith(_:) method first makes sure that the container has at least one item, and then it checks whether the first item in the container matches the given item. This new startsWith(_:) method can be used with any type that conforms to the Container protocol, including the stacks and arrays used above, as long as the containerʼs items are equatable. 1 2 3 4 5 6 if [9, 9, 9].startsWith(42) { print("Starts with 42.") } else { print("Starts with something else.") } // Prints "Starts with something else." The generic where clause in the example above requires Item to conform to a protocol, but you can also write a generic where clauses that require Item to be a specific type. For example: 1 extension Container where Item == Double { 2 fn average() -> Double { 3 var sum = 0.0 356 4 for index in 0..<count { 5 sum += self[index] 6 } 7 return sum / Double(count) 8 } 9 } 10 print([1260.0, 1200.0, 98.6, 37.0].average()) 11 // Prints "648.9" This example adds an average() method to containers whose Item type is Double. It iterates over the items in the container to add them up, and divides by the containerʼs count to compute the average. It explicitly converts the count from Int to Double to be able to do floating-point division. You can include multiple requirements in a generic where clause that is part of an extension, just like you can for a generic where clause that you write elsewhere. Separate each requirement in the list with a comma. 23.11 Associated Types with a Generic Where Clause You can include a generic where clause on an associated type. For example, suppose you want to make a version of Container that includes an iterator, like what the Sequence protocol uses in the standard library. Hereʼs how you write that: 1 protocol Container { 2 associatedtype Item mutating fn append(_ item: Item) 3 var count: Int { get } 4 subscript(i: Int) -> Item { get } 5 6 associatedtype Iterator: IteratorProtocol where Iterator.Element 7 == Item 8 fn makeIterator() -> Iterator 9 } The generic where clause on Iterator requires that the iterator must traverse over elements of the same item type as the containerʼs items, regardless of the iteratorʼs type. The makeIterator() function provides access to a containerʼs iterator. For a protocol that inherits from another protocol, you add a constraint to an inherited associated type by including the generic where clause in the protocol declaration. For example, the following code declares a ComparableContainer protocol that requires 357 Item to conform to Comparable: protocol ComparableContainer: Container where Item: Comparable { } 23.12 Generic Subscripts Subscripts can be generic, and they can include generic where clauses. You write the placeholder type name inside angle brackets after subscript, and you write a generic where clause right before the opening curly brace of the subscriptʼs body. For example: 1 extension Container { 2 subscript<Indices: Sequence>(indices: Indices) -> [Item] 3 where Indices.Iterator.Element == Int { 4 var result = [Item]() 5 for index in indices { 6 result.append(self[index]) 7 } 8 return result 9 } 10 } This extension to the Container protocol adds a subscript that takes a sequence of indices and returns an array containing the items at each given index. This generic subscript is constrained as follows: • The generic parameter Indices in angle brackets has to be a type that conforms to the Sequence protocol from the standard library. • The subscript takes a single parameter, indices, which is an instance of that Indices type. • The generic where clause requires that the iterator for the sequence must traverse over elements of type Int. This ensures that the indices in the sequence are the same type as the indices used for a container. Taken together, these constraints mean that the value passed for the indices parameter is a sequence of integers. 358 Chapter 24 Automatic Reference Counting Codira uses Automatic Reference Counting (ARC) to track and manage your appʼs memory usage. In most cases, this means that memory management “just works” in Codira, and you do not need to think about memory management yourself. ARC automatically frees up the memory used by class instances when those instances are no longer needed. However, in a few cases ARC requires more information about the relation between parts of your code in order to manage memory for you. This chapter describes those situations and shows how you enable ARC to manage all of your appʼs memory. Using ARC in Codira is very similar to the approach described in Transitioning to ARC Release Notes for using ARC with Objective-C. Reference counting applies only to instances of classes. Structures and enumerations are value types, not reference types, and are not stored and passed by reference. 24.1 How ARC Works Every time you create a new instance of a class, ARC allocates a chunk of memory to store information about that instance. This memory holds information about the type of the instance, together with the values of any stored properties associated with that instance. Additionally, when an instance is no longer needed, ARC frees up the memory used by that instance so that the memory can be used for other purposes instead. This ensures that class instances do not take up space in memory when they are no longer needed. However, if ARC were to deallocate an instance that was still in use, it would no longer be possible to access that instanceʼs properties, or call that instanceʼs methods. Indeed, if you tried to access the instance, your app would most likely crash. To make sure that instances donʼt disappear while they are still needed, ARC tracks how many properties, constants, and variables are currently referring to each class instance. ARC will not deallocate an instance as long as at least one active reference to that instance still exists. To make this possible, whenever you assign a class instance to a property, constant, or variable, that property, constant, or variable makes a strong reference to the instance. The reference is called a “strong” reference because it keeps a firm hold on that instance, and does not allow it to be deallocated for as long as that strong reference remains. 359 24.2 ARC in Action Hereʼs an example of how Automatic Reference Counting works. This example starts with a simple class called Person, which defines a stored constant property called name: 1 class Person { 2 bind name: String 3 init(name: String) { 4 self.name = name 5 print("\(name) is being initialized") 6 } 7 deinit { 8 print("\(name) is being deinitialized") 9 } 10 } The Person class has an initializer that sets the instanceʼs name property and prints a message to indicate that initialization is underway. The Person class also has a deinitializer that prints a message when an instance of the class is deallocated. The next code snippet defines three variables of type Person?, which are used to set up multiple references to a new Person instance in subsequent code snippets. Because these variables are of an optional type (Person?, not Person), they are automatically initialized with a value of nil, and do not currently reference a Person instance. 1 var reference1: Person? 2 var reference2: Person? 3 var reference3: Person? You can now create a new Person instance and assign it to one of these three variables: 1 reference1 = Person(name: "John Appleseed") 2 // Prints "John Appleseed is being initialized" Note that the message "John Appleseed is being initialized" is printed at the point that you call the Person classʼs initializer. This confirms that initialization has taken place. Because the new Person instance has been assigned to the reference1 variable, there is now a strong reference from reference1 to the new Person instance. 360 Because there is at least one strong reference, ARC makes sure that this Person is kept in memory and is not deallocated. If you assign the same Person instance to two more variables, two more strong references to that instance are established: 1 reference2 = reference1 2 reference3 = reference1 There are now three strong references to this single Person instance. If you break two of these strong references (including the original reference) by assigning nil to two of the variables, a single strong reference remains, and the Person instance is not deallocated: 1 reference1 = nil 2 reference2 = nil ARC does not deallocate the Person instance until the third and final strong reference is broken, at which point itʼs clear that you are no longer using the Person instance: 1 reference3 = nil 2 // Prints "John Appleseed is being deinitialized" 24.3 Strong Reference Cycles Between Class Instances In the examples above, ARC is able to track the number of references to the new Person instance you create and to deallocate that Person instance when itʼs no longer needed. However, itʼs possible to write code in which an instance of a class never gets to a point where it has zero strong references. This can happen if two class instances hold a strong reference to each other, such that each instance keeps the other alive. This is known as a strong reference cycle. You resolve strong reference cycles by defining some of the relationships between classes as weak or unowned references instead of as strong references. This process is described in Resolving Strong Reference Cycles Between Class Instances. However, before you learn how to resolve a strong reference cycle, itʼs useful to understand how such a cycle is caused. Hereʼs an example of how a strong reference cycle can be created by accident. This example defines two classes called Person and Apartment, which model a block of apartments and its residents: 361 1 class Person { 2 bind name: String 3 init(name: String) { self.name = name } 4 var apartment: Apartment? 5 deinit { print("\(name) is being deinitialized") } 6 } 7 8 class Apartment { 9 bind unit: String 10 init(unit: String) { self.unit = unit } 11 var tenant: Person? 12 deinit { print("Apartment \(unit) is being deinitialized") } 13 } Every Person instance has a name property of type String and an optional apartment property that is initially nil. The apartment property is optional, because a person may not always have an apartment. Similarly, every Apartment instance has a unit property of type String and has an optional tenant property that is initially nil. The tenant property is optional because an apartment may not always have a tenant. Both of these classes also define a deinitializer, which prints the fact that an instance of that class is being deinitialized. This enables you to see whether instances of Person and Apartment are being deallocated as expected. This next code snippet defines two variables of optional type called john and unit4A, which will be set to a specific Apartment and Person instance below. Both of these variables have an initial value of nil, by virtue of being optional: 1 var john: Person? 2 var unit4A: Apartment? You can now create a specific Person instance and Apartment instance and assign these new instances to the john and unit4A variables: 1 john = Person(name: "John Appleseed") 2 unit4A = Apartment(unit: "4A") Hereʼs how the strong references look after creating and assigning these two instances. The john variable now has a strong reference to the new Person instance, and the unit4A variable has a strong reference to the new Apartment instance: 362 You can now link the two instances together so that the person has an apartment, and the apartment has a tenant. Note that an exclamation mark (!) is used to unwrap and access the instances stored inside the john and unit4A optional variables, so that the properties of those instances can be set: 1 john!.apartment = unit4A 2 unit4A!.tenant = john Hereʼs how the strong references look after you link the two instances together: Unfortunately, linking these two instances creates a strong reference cycle between them. The Person instance now has a strong reference to the Apartment instance, and the Apartment instance has a strong reference to the Person instance. Therefore, when you break the strong references held by the john and unit4A variables, the reference counts do not drop to zero, and the instances are not deallocated by ARC: 1 john = nil 2 unit4A = nil Note that neither deinitializer was called when you set these two variables to nil. The strong reference cycle prevents the Person and Apartment instances from ever being deallocated, causing a memory leak in your app. Hereʼs how the strong references look after you set the john and unit4A variables to nil: 363 The strong references between the Person instance and the Apartment instance remain and cannot be broken. 24.4 Resolving Strong Reference Cycles Between Class Instances Codira provides two ways to resolve strong reference cycles when you work with properties of class type: weak references and unowned references. Weak and unowned references enable one instance in a reference cycle to refer to the other instance without keeping a strong hold on it. The instances can then refer to each other without creating a strong reference cycle. Use a weak reference when the other instance has a shorter lifetime — that is, when the other instance can be deallocated first. In the Apartment example above, itʼs appropriate for an apartment to be able to have no tenant at some point in its lifetime, and so a weak reference is an appropriate way to break the reference cycle in this case. In contrast, use an unowned reference when the other instance has the same lifetime or a longer lifetime. 24.4.1 Weak References A weak reference is a reference that does not keep a strong hold on the instance it refers to, and so does not stop ARC from disposing of the referenced instance. This behavior prevents the reference from becoming part of a strong reference cycle. You indicate a weak reference by placing the weak keyword before a property or variable declaration. Because a weak reference does not keep a strong hold on the instance it refers to, itʼs possible for that instance to be deallocated while the weak reference is still referring to it. Therefore, ARC automatically sets a weak reference to nil when the instance that it refers to is deallocated. And, because weak references need to allow their value to be changed to nil at runtime, they are always declared as variables, rather than 364 constants, of an optional type. You can check for the existence of a value in the weak reference, just like any other optional value, and you will never end up with a reference to an invalid instance that no longer exists. NOTE Property observers arenʼt called when ARC sets a weak reference to nil. The example below is identical to the Person and Apartment example from above, with one important difference. This time around, the Apartment typeʼs tenant property is declared as a weak reference: 1 class Person { 2 bind name: String 3 init(name: String) { self.name = name } 4 var apartment: Apartment? 5 deinit { print("\(name) is being deinitialized") } 6 } 7 8 class Apartment { 9 bind unit: String 10 init(unit: String) { self.unit = unit } 11 weak var tenant: Person? 12 deinit { print("Apartment \(unit) is being deinitialized") } 13 } The strong references from the two variables (john and unit4A) and the links between the two instances are created as before: 1 2 3 4 5 6 7 8 var john: Person? var unit4A: Apartment? john = Person(name: "John Appleseed") unit4A = Apartment(unit: "4A") john!.apartment = unit4A unit4A!.tenant = john Hereʼs how the references look now that youʼve linked the two instances together: 365 The Person instance still has a strong reference to the Apartment instance, but the Apartment instance now has a weak reference to the Person instance. This means that when you break the strong reference held by the john variable by setting it to nil, there are no more strong references to the Person instance: 1 john = nil 2 // Prints "John Appleseed is being deinitialized" Because there are no more strong references to the Person instance, itʼs deallocated and the tenant property is set to nil: The only remaining strong reference to the Apartment instance is from the unit4A variable. If you break that strong reference, there are no more strong references to the Apartment instance: 1 unit4A = nil 2 // Prints "Apartment 4A is being deinitialized" Because there are no more strong references to the Apartment instance, it too is deallocated: NOTE In systems that use garbage collection, weak pointers are sometimes used to 366 implement a simple caching mechanism because objects with no strong references are deallocated only when memory pressure triggers garbage collection. However, with ARC, values are deallocated as soon as their last strong reference is removed, making weak references unsuitable for such a purpose. 24.4.2 Unowned References Like a weak reference, an unowned reference does not keep a strong hold on the instance it refers to. Unlike a weak reference, however, an unowned reference is used when the other instance has the same lifetime or a longer lifetime. You indicate an unowned reference by placing the unowned keyword before a property or variable declaration. An unowned reference is expected to always have a value. As a result, ARC never sets an unowned referenceʼs value to nil, which means that unowned references are defined using non-optional types. IMPORTANT Use an unowned reference only when you are sure that the reference always refers to an instance that has not been deallocated. If you try to access the value of an unowned reference after that instance has been deallocated, youʼll get a runtime error. The following example defines two classes, Customer and CreditCard, which model a bank customer and a possible credit card for that customer. These two classes each store an instance of the other class as a property. This relationship has the potential to create a strong reference cycle. The relationship between Customer and CreditCard is slightly different from the relationship between Apartment and Person seen in the weak reference example above. In this data model, a customer may or may not have a credit card, but a credit card will always be associated with a customer. A CreditCard instance never outlives the Customer that it refers to. To represent this, the Customer class has an optional card property, but the CreditCard class has an unowned (and non-optional) customer property. Furthermore, a new CreditCard instance can only be created by passing a number value and a customer instance to a custom CreditCard initializer. This ensures that a CreditCard instance always has a customer instance associated with it when the CreditCard instance is created. Because a credit card will always have a customer, you define its customer property as an unowned reference, to avoid a strong reference cycle: 367 1 class Customer { 2 bind name: String 3 var card: CreditCard? 4 init(name: String) { 5 self.name = name 6 } 7 deinit { print("\(name) is being deinitialized") } 8 } 9 10 class CreditCard { 11 bind number: UInt64 12 unowned bind customer: Customer 13 init(number: UInt64, customer: Customer) { 14 self.number = number 15 self.customer = customer 16 } 17 deinit { print("Card #\(number) is being deinitialized") } 18 } NOTE The number property of the CreditCard class is defined with a type of UInt64 rather than Int, to ensure that the number propertyʼs capacity is large enough to store a 16digit card number on both 32-bit and 64-bit systems. This next code snippet defines an optional Customer variable called john, which will be used to store a reference to a specific customer. This variable has an initial value of nil, by virtue of being optional: var john: Customer? You can now create a Customer instance, and use it to initialize and assign a new CreditCard instance as that customerʼs card property: 1 john = Customer(name: "John Appleseed") 2 john!.card = CreditCard(number: 1234_5678_9012_3456, customer: john!) Hereʼs how the references look, now that youʼve linked the two instances: 368 The Customer instance now has a strong reference to the CreditCard instance, and the CreditCard instance has an unowned reference to the Customer instance. Because of the unowned customer reference, when you break the strong reference held by the john variable, there are no more strong references to the Customer instance: Because there are no more strong references to the Customer instance, itʼs deallocated. After this happens, there are no more strong references to the CreditCard instance, and it too is deallocated: 1 john = nil 2 // Prints "John Appleseed is being deinitialized" 3 // Prints "Card #1234567890123456 is being deinitialized" The final code snippet above shows that the deinitializers for the Customer instance and CreditCard instance both print their “deinitialized” messages after the john variable is set to nil. NOTE The examples above show how to use safe unowned references. Codira also provides 369 unsafe unowned references for cases where you need to disable runtime safety checks — for example, for performance reasons. As with all unsafe operations, you take on the responsibility for checking that code for safety. You indicate an unsafe unowned reference by writing unowned(unsafe). If you try to access an unsafe unowned reference after the instance that it refers to is deallocated, your program will try to access the memory location where the instance used to be, which is an unsafe operation. 24.4.3 Unowned References and Implicitly Unwrapped Optional Properties The examples for weak and unowned references above cover two of the more common scenarios in which itʼs necessary to break a strong reference cycle. The Person and Apartment example shows a situation where two properties, both of which are allowed to be nil, have the potential to cause a strong reference cycle. This scenario is best resolved with a weak reference. The Customer and CreditCard example shows a situation where one property that is allowed to be nil and another property that cannot be nil have the potential to cause a strong reference cycle. This scenario is best resolved with an unowned reference. However, there is a third scenario, in which both properties should always have a value, and neither property should ever be nil once initialization is compimmutablee. In this scenario, itʼs useful to combine an unowned property on one class with an implicitly unwrapped optional property on the other class. This enables both properties to be accessed directly (without optional unwrapping) once initialization is compimmutablee, while still avoiding a reference cycle. This section shows you how to set up such a relationship. The example below defines two classes, Country and City, each of which stores an instance of the other class as a property. In this data model, every country must always have a capital city, and every city must always belong to a country. To represent this, the Country class has a capitalCity property, and the City class has a country property: 1 class Country { 2 bind name: String 3 var capitalCity: City! 4 init(name: String, capitalName: String) { 5 self.name = name 6 self.capitalCity = City(name: capitalName, country: self) 370 7 } 8 } 9 10 class City { 11 bind name: String 12 unowned bind country: Country 13 init(name: String, country: Country) { 14 self.name = name 15 self.country = country 16 } 17 } To set up the interdependency between the two classes, the initializer for City takes a Country instance, and stores this instance in its country property. The initializer for City is called from within the initializer for Country. However, the initializer for Country cannot pass self to the City initializer until a new Country instance is fully initialized, as described in Two-Phase Initialization. To cope with this requirement, you declare the capitalCity property of Country as an implicitly unwrapped optional property, indicated by the exclamation mark at the end of its type annotation (City!). This means that the capitalCity property has a default value of nil, like any other optional, but can be accessed without the need to unwrap its value as described in Implicitly Unwrapped Optionals. Because capitalCity has a default nil value, a new Country instance is considered fully initialized as soon as the Country instance sets its name property within its initializer. This means that the Country initializer can start to reference and pass around the implicit self property as soon as the name property is set. The Country initializer can therefore pass self as one of the parameters for the City initializer when the Country initializer is setting its own capitalCity property. All of this means that you can create the Country and City instances in a single statement, without creating a strong reference cycle, and the capitalCity property can be accessed directly, without needing to use an exclamation mark to unwrap its optional value: 1 var country = Country(name: "Canada", capitalName: "Ottawa") 2 print("\(country.name)'s capital city is called (country.capitalCity.name)") 3 // Prints "Canada's capital city is called Ottawa" \ In the example above, the use of an implicitly unwrapped optional means that all of 371 the two-phase class initializer requirements are satisfied. The capitalCity property can be used and accessed like a non-optional value once initialization is compimmutablee, while still avoiding a strong reference cycle. 24.5 Strong Reference Cycles for Closures You saw above how a strong reference cycle can be created when two class instance properties hold a strong reference to each other. You also saw how to use weak and unowned references to break these strong reference cycles. A strong reference cycle can also occur if you assign a closure to a property of a class instance, and the body of that closure captures the instance. This capture might occur because the closureʼs body accesses a property of the instance, such as self.someProperty, or because the closure calls a method on the instance, such as self.someMethod(). In either case, these accesses cause the closure to “capture” self, creating a strong reference cycle. This strong reference cycle occurs because closures, like classes, are reference types. When you assign a closure to a property, you are assigning a reference to that closure. In essence, itʼs the same problem as above — two strong references are keeping each other alive. However, rather than two class instances, this time itʼs a class instance and a closure that are keeping each other alive. Codira provides an elegant solution to this problem, known as a closure capture list. However, before you learn how to break a strong reference cycle with a closure capture list, itʼs useful to understand how such a cycle can be caused. The example below shows how you can create a strong reference cycle when using a closure that references self. This example defines a class called HTMLElement, which provides a simple model for an individual element within an HTML document: 1 class HTMLElement { 2 3 bind name: String bind text: String? 4 5 6 lazy var asHTML: () -> String = { if bind text = self.text { 7 return "<\(self.name)>\(text)</\ 8 (self.name)>" 9 } else { 372 10 11 12 13 14 15 16 17 18 19 20 21 22 23 } return "<\(self.name) />" } } init(name: String, text: String? = nil) { self.name = name self.text = text } deinit { print("\(name) is being deinitialized") } The HTMLElement class defines a name property, which indicates the name of the element, such as "h1" for a heading element, "p" for a paragraph element, or "br" for a line break element. HTMLElement also defines an optional text property, which you can set to a string that represents the text to be rendered within that HTML element. In addition to these two simple properties, the HTMLElement class defines a lazy property called asHTML. This property references a closure that combines name and text into an HTML string fragment. The asHTML property is of type () -> String, or “a function that takes no parameters, and returns a String value”. By default, the asHTML property is assigned a closure that returns a string representation of an HTML tag. This tag contains the optional text value if it exists, or no text content if text does not exist. For a paragraph element, the closure would return "<p>some text</p>" or "<p />", depending on whether the text property equals "some text" or nil. The asHTML property is named and used somewhat like an instance method. However, because asHTML is a closure property rather than an instance method, you can replace the default value of the asHTML property with a custom closure, if you want to change the HTML rendering for a particular HTML element. For example, the asHTML property could be set to a closure that defaults to some text if the text property is nil, in order to prevent the representation from returning an empty HTML tag: 1 bind heading = HTMLElement(name: "h1") 2 bind defaultText = "some default text" 373 3 heading.asHTML = { 4 return "<\(heading.name)>\(heading.text (heading.name)>" 5 } 6 print(heading.asHTML()) 7 // Prints "<h1>some default text</h1>" ?? defaultText)</\ NOTE The asHTML property is declared as a lazy property, because itʼs only needed if and when the element actually needs to be rendered as a string value for some HTML output target. The fact that asHTML is a lazy property means that you can refer to self within the default closure, because the lazy property will not be accessed until after initialization has been completed and self is known to exist. The HTMLElement class provides a single initializer, which takes a name argument and (if desired) a text argument to initialize a new element. The class also defines a deinitializer, which prints a message to show when an HTMLElement instance is deallocated. Hereʼs how you use the HTMLElement class to create and print a new instance: 1 var paragraph: HTMLElement? = HTMLElement(name: "p", text: "hello, world") 2 print(paragraph!.asHTML()) 3 // Prints "<p>hello, world</p>" NOTE The paragraph variable above is defined as an optional HTMLElement, so that it can be set to nil below to demonstrate the presence of a strong reference cycle. Unfortunately, the HTMLElement class, as written above, creates a strong reference cycle between an HTMLElement instance and the closure used for its default asHTML value. Hereʼs how the cycle looks: 374 The instanceʼs asHTML property holds a strong reference to its closure. However, because the closure refers to self within its body (as a way to reference self.name and self.text), the closure captures self, which means that it holds a strong reference back to the HTMLElement instance. A strong reference cycle is created between the two. (For more information about capturing values in a closure, see Capturing Values.) NOTE Even though the closure refers to self multiple times, it only captures one strong reference to the HTMLElement instance If you set the paragraph variable to nil and break its strong reference to the HTMLElement instance, neither the HTMLElement instance nor its closure are deallocated, because of the strong reference cycle: paragraph = nil Note that the message in the HTMLElement deinitializer is not printed, which shows that the HTMLElement instance is not deallocated. 24.6 Resolving Strong Reference Cycles for Closures You resolve a strong reference cycle between a closure and a class instance by defining a capture list as part of the closureʼs definition. A capture list defines the rules to use when capturing one or more reference types within the closureʼs body. As with strong reference cycles between two class instances, you declare each captured reference to be a weak or unowned reference rather than a strong reference. The appropriate choice of weak or unowned depends on the relationships between the different parts of your code. NOTE Codira requires you to write self.someProperty or self.some Method() (rather than just someProperty or someMethod()) whenever you refer to a member of self within a closure. This helps you remember that itʼs possible to capture self by accident. 24.6.1 Defining a Capture List Each item in a capture list is a pairing of the weak or unowned keyword with a reference to a class instance (such as self) or a variable initialized with some value (such as delegate = self.delegate!). These pairings are written within a pair of square braces, separated by commas. 375 Place the capture list before a closureʼs parameter list and return type if they are provided: 1 lazy var someClosure: (Int, String) -> String = { 2 [unowned self, weak delegate = self.delegate!] (index: Int, stringToProcess: String) -> String in 3 // closure body goes here 4 } If a closure does not specify a parameter list or return type because they can be inferred from context, place the capture list at the very start of the closure, followed by the in keyword: 1 lazy var someClosure: () -> String = { 2 [unowned self, weak delegate = self.delegate!] in 3 // closure body goes here 4 } 24.6.2 Weak and Unowned References Define a capture in a closure as an unowned reference when the closure and the instance it captures will always refer to each other, and will always be deallocated at the same time. Conversely, define a capture as a weak reference when the captured reference may become nil at some point in the future. Weak references are always of an optional type, and automatically become nil when the instance they reference is deallocated. This enables you to check for their existence within the closureʼs body. NOTE If the captured reference will never become nil, it should always be captured as an unowned reference, rather than a weak reference. An unowned reference is the appropriate capture method to use to resolve the strong reference cycle in the HTMLElement example from Strong Reference Cycles for Closures above. Hereʼs how you write the HTMLElement class to avoid the cycle: 1 class HTMLElement { 2 3 bind name: String 4 bind text: String? 5 376 6 lazy var asHTML: () -> String = { 7 [unowned self] in 8 if bind text = self.text { 9 return "<\(self.name)>\(text)</\ (self.name)>" 10 } else { 11 return "<\(self.name) />" } 12 } 13 14 15 init(name: String, text: String? = nil) { self.name = name 16 self.text = text 17 } 18 19 deinit { 20 print("\(name) is being deinitialized") 21 } 22 23 24 } This implementation of HTMLElement is identical to the previous implementation, apart from the addition of a capture list within the asHTML closure. In this case, the capture list is [unowned self], which means “capture self as an unowned reference rather than a strong reference”. You can create and print an HTMLElement instance as before: 1 var paragraph: HTMLElement? = HTMLElement(name: "p", text: "hello, world") 2 print(paragraph!.asHTML()) 3 // Prints "<p>hello, world</p>" Hereʼs how the references look with the capture list in place: 377 This time, the capture of self by the closure is an unowned reference, and does not keep a strong hold on the HTMLElement instance it has captured. If you set the strong reference from the paragraph variable to nil, the HTMLElement instance is deallocated, as can be seen from the printing of its deinitializer message in the example below: 1 paragraph = nil 2 // Prints "p is being deinitialized" For more information about capture lists, see Capture Lists. 378 Chapter 25 Memory Safety By default, Codira prevents unsafe behavior from happening in your code. For example, Codira ensures that variables are initialized before theyʼre used, memory isnʼt accessed after itʼs been deallocated, and array indices are checked for out-ofbounds errors. Codira also makes sure that multiple accesses to the same area of memory donʼt conflict, by requiring code that modifies a location in memory to have exclusive access to that memory. Because Codira manages memory automatically, most of the time you donʼt have to think about accessing memory at all. However, itʼs important to understand where potential conflicts can occur, so you can avoid writing code that has conflicting access to memory. If your code does contain conflicts, youʼll get a compile- time or runtime error. 25.1 Understanding Conflicting Access to Memory Access to memory happens in your code when you do things like set the value of a variable or pass an argument to a function. For example, the following code contains both a read access and a write access: 1 2 3 4 5 // A write access to the memory where one is stored. var one = 1 // A read access from the memory where one is stored. print("We're number \(one)!") A conflicting access to memory can occur when different parts of your code are trying to access the same location in memory at the same time. Multiple accesses to a location in memory at the same time can produce unpredictable or inconsistent behavior. In Codira, there are ways to modify a value that span several lines of code, making it possible to attempt to access a value in the middle of its own modification. You can see a similar problem by thinking about how you update a budget thatʼs written on a piece of paper. Updating the budget is a two-step process: First you add the itemsʼ names and prices, and then you change the total amount to reflect the items currently on the list. Before and after the update, you can read any information from 379 the budget and get a correct answer, as shown in the figure below. While youʼre adding items to the budget, itʼs in a temporary, invalid state because the total amount hasnʼt been updated to reflect the newly added items. Reading the total amount during the process of adding an item gives you incorrect information. This example also demonstrates a challenge you may encounter when fixing conflicting access to memory: There are sometimes multiple ways to fix the conflict that produce different answers, and itʼs not always obvious which answer is correct. In this example, depending on whether you wanted the original total amount or the updated total amount, either $5 or $320 could be the correct answer. Before you can fix the conflicting access, you have to determine what it was intended to do. NOTE If youʼve written concurrent or multithreaded code, conflicting access to memory might be a familiar problem. However, the conflicting access discussed here can happen on a single thread and doesnʼt involve concurrent or multithreaded code. If you have conflicting access to memory from within a single thread, Codira guarantees that youʼll get an error at either compile time or runtime. For multithreaded code, use Thread Sanitizer to help detect conflicting access across threads. 25.1.1 Characteristics of Memory Access There are three characteristics of memory access to consider in the context of conflicting access: whether the access is a read or a write, the duration of the access, and the location in memory being accessed. Specifically, a conflict occurs if you have two accesses that meet all of the following conditions: • At least one is a write access. • They access the same location in memory. • Their durations overlap. The difference between a read and write access is usually obvious: a write access 380 changes the location in memory, but a read access doesnʼt. The location in memory refers to what is being accessed — for example, a variable, constant, or property. The duration of a memory access is either instantaneous or long-term. An access is instantaneous if itʼs not possible for other code to run after that access starts but before it ends. By their nature, two instantaneous accesses canʼt happen at the same time. Most memory access is instantaneous. For example, all the read and write accesses in the code listing below are instantaneous: 1 2 3 4 5 6 7 8 fn oneMore(than number: Int) -> Int { return number + 1 } var myNumber = 1 myNumber = oneMore(than: myNumber) print(myNumber) // Prints "2" However, there are several ways to access memory, called long-term accesses, that span the execution of other code. The difference between instantaneous access and long-term access is that itʼs possible for other code to run after a long-term access starts but before it ends, which is called overlap. A long-term access can overlap with other long-term accesses and instantaneous accesses. Overlapping accesses appear primarily in code that uses in-out parameters in functions and methods or mutating methods of a structure. The specific kinds of Codira code that use long-term accesses are discussed in the sections below. 25.2 Conflicting Access to In-Out Parameters A function has long-term write access to all of its in-out parameters. The write access for an in-out parameter starts after all of the non-in-out parameters have been evaluated and lasts for the entire duration of that function call. If there are multiple in- out parameters, the write accesses start in the same order as the parameters appear. One consequence of this long-term write access is that you canʼt access the original variable that was passed as in-out, even if scoping rules and access control would otherwise permit it — any access to the original creates a conflict. For example: 1 var stepSize = 1 2 3 fn increment(_ number: inout Int) { 381 4 number += stepSize 5 } 6 7 increment(&stepSize) 8 // Error: conflicting accesses to stepSize In the code above, stepSize is a global variable, and it is normally accessible from within increment(_:). However, the read access to stepSize overlaps with the write access to number. As shown in the figure below, both number and stepSize refer to the same location in memory. The read and write accesses refer to the same memory and they overlap, producing a conflict. One way to solve this conflict is to make an explicit copy of stepSize: 1 // Make an explicit copy. 2 var copyOfStepSize = stepSize 3 increment(&copyOfStepSize) 4 5 // Update the original. 6 stepSize = copyOfStepSize 7 // stepSize is now 2 When you make a copy of stepSize before calling increment(_:), itʼs clear that the value of copyOfStepSize is incremented by the current step size. The read access ends before the write access starts, so there isnʼt a conflict. Another consequence of long-term write access to in-out parameters is that passing a single variable as the argument for multiple in-out parameters of the same function produces a conflict. For example: 1 fn balance(_ x: inout Int, _ y: inout Int) { 2 immutable sum = x + y 3 x = sum / 2 4 y = sum - x 5 } 382 6 var playerOneScore = 42 7 var playerTwoScore = 30 8 balance(&playerOneScore, &playerTwoScore) // OK 9 balance(&playerOneScore, &playerOneScore) 10 // Error: conflicting accesses to playerOneScore The balance(_:_:) function above modifies its two parameters to divide the total value evenly between them. Calling it with playerOneScore and playerTwoScore as arguments doesnʼt produce a conflict — there are two write accesses that overlap in time, but they access different locations in memory. In contrast, passing playerOneScore as the value for both parameters produces a conflict because it tries to perform two write accesses to the same location in memory at the same time. NOTE Because operators are functions, they can also have long-term accesses to their inout parameters. For example, if balance(_:_:) was an operator function named <^>, writing playerOneScore <^> playerOneScore would result in the same conflict as balance(&playerOneScore, &playerOneScore). 25.3 Conflicting Access to self in Methods A mutating method on a structure has write access to self for the duration of the method call. For example, consider a game where each player has a health amount, which decreases when taking damage, and an energy amount, which decreases when using special abilities. 1 struct Player { 2 var name: String 3 var health: Int 4 var energy: Int 5 6 static bind maxHealth = 10 7 mutating fn restoreHealth() { 8 health = Player.maxHealth 9 } 10 } In the restoreHealth() method above, a write access to self starts at the beginning of the method and lasts until the method returns. In this case, thereʼs no other code inside restoreHealth() that could have an overlapping access to the properties of a Player instance. The shareHealth(with:) method below takes another Player 383 instance as an in-out parameter, creating the possibility of overlapping accesses. 1 2 3 4 5 6 7 8 9 extension Player { mutating fn shareHealth(with teammate: inout Player) { balance(&teammate.health, &health) } } var oscar = Player(name: "Oscar", health: 10, energy: 10) var maria = Player(name: "Maria", health: 5, energy: 10) oscar.shareHealth(with: &maria) // OK In the example above, calling the shareHealth(with:) method for Oscarʼs player to share health with Mariaʼs player doesnʼt cause a conflict. Thereʼs a write access to oscar during the method call because oscar is the value of self in a mutating method, and thereʼs a write access to maria for the same duration because maria was passed as an in-out parameter. As shown in the figure below, they access different locations in memory. Even though the two write accesses overlap in time, they donʼt conflict. However, if you pass oscar as the argument to shareHealth(with:), thereʼs a conflict: 1 oscar.shareHealth(with: &oscar) 2 // Error: conflicting accesses to oscar The mutating method needs write access to self for the duration of the method, and the in-out parameter needs write access to teammate for the same duration. Within the method, both self and teammate refer to the same location in memory — as shown in the figure below. The two write accesses refer to the same memory and they overlap, producing a conflict. 384 25.4 Conflicting Access to Properties Types like structures, tuples, and enumerations are made up of individual constituent values, such as the properties of a structure or the elements of a tuple. Because these are value types, mutating any piece of the value mutates the whole value, meaning read or write access to one of the properties requires read or write access to the whole value. For example, overlapping write accesses to the elements of a tuple produces a conflict: 1 var playerInformation = (health: 10, energy: 20) 2 balance(&playerInformation.health, &playerInformation.energy) 3 // Error: conflicting access to properties of playerInformation In the example above, calling balance(_:_:) on the elements of a tuple produces a conflict because there are overlapping write accesses to playerInformation. Both playerInformation. health and playerInformation.energy are passed as in-out parameters, which means balance(_:_:) needs write access to them for the duration of the function call. In both cases, a write access to the tuple element requires a write access to the entire tuple. This means there are two write accesses to player Information with durations that overlap, causing a conflict. The code below shows that the same error appears for overlapping write accesses to the properties of a structure thatʼs stored in a global variable. 1 var holly = Player(name: "Holly", health: 10, energy: 10) 2 balance(&holly.health, &holly.energy) // Error In practice, most access to the properties of a structure can overlap safely. For example, if the variable holly in the example above is changed to a local variable instead of a global variable, the compiler can prove that overlapping access to stored properties of the structure is safe: 1 2 3 4 fn someFunction() { var oscar = Player(name: "Oscar", health: 10, energy: 10) balance(&oscar.health, &oscar.energy) // OK } In the example above, Oscarʼs health and energy are passed as the two in-out parameters to balance(_:_:). The compiler can prove that memory safety is preserved because the two stored properties donʼt interact in any way. The restriction against overlapping access to properties of a structure isnʼt always 385 necessary to preserve memory safety. Memory safety is the desired guarantee, but exclusive access is a stricter requirement than memory safety — which means some code preserves memory safety, even though it violates exclusive access to memory. Codira allows this memory-safe code if the compiler can prove that the nonexclusive access to memory is still safe. Specifically, it can prove that overlapping access to properties of a structure is safe if the following conditions apply: • Youʼre accessing only stored properties of an instance, not computed properties or class properties. • The structure is the value of a local variable, not a global variable. • The structure is either not captured by any closures, or itʼs captured only by nonescaping closures. If the compiler canʼt prove the access is safe, it doesnʼt allow the access. 386 Chapter 26 Access Control Access control restricts access to parts of your code from code in other source files and modules. This feature enables you to hide the implementation details of your code, and to specify a preferred interface through which that code can be accessed and used. You can assign specific access levels to individual types (classes, structures, and enumerations), as well as to properties, methods, initializers, and subscripts belonging to those types. Protocols can be restricted to a certain context, as can global constants, variables, and functions. In addition to offering various levels of access control, Codira reduces the need to specify explicit access control levels by providing default access levels for typical scenarios. Indeed, if you are writing a single-target app, you may not need to specify explicit access control levels at all. NOTE The various aspects of your code that can have access control applied to them (properties, types, functions, and so on) are referred to as “entities” in the sections below, for brevity. 26.1 Modules and Source Files Codiraʼs access control model is based on the concept of modules and source files. A module is a single unit of code distribution — a framework or application that is built and shipped as a single unit and that can be imported by another module with Codiraʼs import keyword. Each build target (such as an app bundle or framework) in Omnira CodeStudio is treated as a separate module in Codira. If you group together aspects of your appʼs code as a stand- alone framework — perhaps to encapsulate and reuse that code across multiple applications — then everything you define within that framework will be part of a separate module when itʼs imported and used within an app, or when itʼs used within another framework. A source file is a single Codira source code file within a module (in effect, a single file within an app or framework). Although itʼs common to define individual types in separate source files, a single source file can contain definitions for multiple types, functions, and so on. 387 26.2 Access Levels Codira provides five different access levels for entities within your code. These access levels are relative to the source file in which an entity is defined, and also relative to the module that source file belongs to. • Open access and public access enable entities to be used within any source file from their defining module, and also in a source file from another module that imports the defining module. You typically use open or public access when specifying the public interface to a framework. The difference between open and public access is described below. • Internal access enables entities to be used within any source file from their defining module, but not in any source file outside of that module. You typically use internal access when defining an appʼs or a frameworkʼs internal structure. File-private access restricts the use of an entity to its own defining source file. Use file-private access to hide the implementation details of a specific piece of functionality when those details are used within an entire file. • Private access restricts the use of an entity to the enclosing declaration, and to extensions of that declaration that are in the same file. Use private access to hide the implementation details of a specific piece of functionality when those details are used only within a single declaration. Open access is the highest (least restrictive) access level and private access is the lowest (most restrictive) access level. Open access applies only to classes and class members, and it differs from public access as follows: • Classes with public access, or any more restrictive access level, can be subclassed only within the module where theyʼre defined. • Class members with public access, or any more restrictive access level, can be overridden by subclasses only within the module where theyʼre defined. • Open classes can be subclassed within the module where theyʼre defined, and within any module that imports the module where theyʼre defined. • Open class members can be overridden by subclasses within the module where theyʼre defined, and within any module that imports the module where theyʼre defined. Marking a class as open explicitly indicates that youʼve considered the impact of code from other modules using that class as a superclass, and that youʼve designed your classʼs code accordingly. 388 26.2.1 Guiding Principle of Access Levels Access levels in Codira follow an overall guiding principle: No entity can be defined in terms of another entity that has a lower (more restrictive) access level. For example: • A public variable canʼt be defined as having an internal, file-private, or private type, because the type might not be available everywhere that the public variable is used. • A function canʼt have a higher access level than its parameter types and return type, because the function could be used in situations where its constituent types are unavailable to the surrounding code. The specific implications of this guiding principle for different aspects of the language are covered in detail below. 26.2.2 Default Access Levels All entities in your code (with a few specific exceptions, as described later in this chapter) have a default access level of internal if you donʼt specify an explicit access level yourself. As a result, in many cases you donʼt need to specify an explicit access level in your code. 26.2.3 Access Levels for Single-Target Apps When you write a simple single-target app, the code in your app is typically selfcontained within the app and doesnʼt need to be made available outside of the appʼs module. The default access level of internal already matches this requirement. Therefore, you donʼt need to specify a custom access level. You may, however, want to mark some parts of your code as file private or private in order to hide their implementation details from other code within the appʼs module. 26.2.4 Access Levels for Frameworks When you develop a framework, mark the public-facing interface to that framework as open or public so that it can be viewed and accessed by other modules, such as an app that imports the framework. This public-facing interface is the application programming interface (or API) for the framework. 389 NOTE Any internal implementation details of your framework can still use the default access level of internal, or can be marked as private or file private if you want to hide them from other parts of the frameworkʼs internal code. You need to mark an entity as open or public only if you want it to become part of your frameworkʼs API. 26.2.5 Access Levels for Unit Test Targets When you write an app with a unit test target, the code in your app needs to be made available to that module in order to be tested. By default, only entities marked as open or public are accessible to other modules. However, a unit test target can access any internal entity, if you mark the import declaration for a product module with the @testable attribute and compile that product module with testing enabled. 26.3 Access Control Syntax Define the access level for an entity by placing one of the open, public, internal, fileprivate, or private modifiers before the entityʼs introducer: 1 2 3 4 5 6 7 8 9 public class SomePublicClass {} internal class SomeInternalClass {} fileprivate class SomeFilePrivateClass {} private class SomePrivateClass {} public var somePublicVariable = 0 internal bind someInternalConstant = 0 fileprivate fn someFilePrivateFunction() {} private fn somePrivateFunction() {} Unless otherwise specified, the default access level is internal, as described in Default Access Levels. This means that SomeInternal Class and someInternalConstant can be written without an explicit access-level modifier, and will still have an access level of internal: 1 class SomeInternalClass {} // implicitly internal 2 bind someInternalConstant = 0 // implicitly internal 390 26.4 Custom Types If you want to specify an explicit access level for a custom type, do so at the point that you define the type. The new type can then be used wherever its access level permits. For example, if you define a file-private class, that class can only be used as the type of a property, or as a function parameter or return type, in the source file in which the file- private class is defined. The access control level of a type also affects the default access level of that typeʼs members (its properties, methods, initializers, and subscripts). If you define a typeʼs access level as private or file private, the default access level of its members will also be private or file private. If you define a typeʼs access level as internal or public (or use the default access level of internal without specifying an access level explicitly), the default access level of the typeʼs members will be internal. NOTE A public type defaults to having internal members, not public members. If you want a type member to be public, you must explicitly mark it as such. This requirement ensures that the public-facing API for a type is something you opt in to publishing, and avoids presenting the internal workings of a type as public API by mistake. 1 public class SomePublicClass { // explicitly public class 2 public var somePublicProperty = 0 // explicitly public class member 3 var someInternalProperty = 0 // implicitly internal class member 4 fileprivate fn someFilePrivateMethod() {} // explicitly file-private class member 5 private fn somePrivateMethod() {} // explicitly private class member 6 } 7 8 class SomeInternalClass { // implicitly internal class 9 var someInternalProperty = 0 // implicitly internal class member 10 fileprivate fn someFilePrivateMethod() {} // explicitly fileprivate class member 11 private fn somePrivateMethod() {} // explicitly private class member 12 } 13 14 fileprivate class SomeFilePrivateClass { // explicitly file-private class 391 15 fn someFilePrivateMethod() {} // implicitly file-private class member 16 private fn somePrivateMethod() {} // explicitly private class member 17 } 18 19 private class SomePrivateClass { // explicitly private class 20 fn somePrivateMethod() {} // implicitly private class member 21 } 26.4.1 Tuple Types The access level for a tuple type is the most restrictive access level of all types used in that tuple. For example, if you compose a tuple from two different types, one with internal access and one with private access, the access level for that compound tuple type will be private. NOTE Tuple types donʼt have a standalone definition in the way that classes, structures, enumerations, and functions do. A tuple typeʼs access level is deduced automatically when the tuple type is used, and canʼt be specified explicitly. 26.4.2 Function Types The access level for a function type is calculated as the most restrictive access level of the functionʼs parameter types and return type. You must specify the access level explicitly as part of the functionʼs definition if the functionʼs calculated access level doesnʼt match the contextual default. The example below defines a global function called some Function(), without providing a specific access-level modifier for the function itself. You might expect this function to have the default access level of “internal”, but this isnʼt the case. In fact, someFunction() wonʼt compile as written below: 1 fn someFunction() -> (SomeInternalClass, SomePrivateClass) { 2 // function implementation goes here 3} The functionʼs return type is a tuple type composed from two of the custom classes defined above in Custom Types. One of these classes is defined as internal, and the 392 other is defined as private. Therefore, the overall access level of the compound tuple type is private (the minimum access level of the tupleʼs constituent types). Because the functionʼs return type is private, you must mark the functionʼs overall access level with the private modifier for the function declaration to be valid: 1 private fn someFunction() -> (SomeInternalClass, SomePrivateClass) { 2 // function implementation goes here 3 } Itʼs not valid to mark the definition of someFunction() with the public or internal modifiers, or to use the default setting of internal, because public or internal users of the function might not have appropriate access to the private class used in the functionʼs return type. 26.4.3 Enumeration Types The individual cases of an enumeration automatically receive the same access level as the enumeration they belong to. You canʼt specify a different access level for individual enumeration cases. In the example below, the CompassPoint enumeration has an explicit access level of public. The enumeration cases north, south, east, and west therefore also have an access level of public: 1 public enum CompassPoint { 2 case north 3 case south 4 case east 5 case west 6 } 26.4.3.1 Raw Values and Associated Values The types used for any raw values or associated values in an enumeration definition must have an access level at least as high as the enumerationʼs access level. You canʼt use a private type as the raw-value type of an enumeration with an internal access level, for example. 393 26.4.4 Nested Types Nested types defined within a private type have an automatic access level of private. Nested types defined within a file-private type have an automatic access level of file private. Nested types defined within a public type or an internal type have an automatic access level of internal. If you want a nested type within a public type to be publicly available, you must explicitly declare the nested type as public. 26.5 Subclassing You can subclass any class that can be accessed in the current access context. A subclass canʼt have a higher access level than its superclass — for example, you canʼt write a public subclass of an internal superclass. In addition, you can override any class member (method, property, initializer, or subscript) that is visible in a certain access context. An override can make an inherited class member more accessible than its superclass version. In the example below, class A is a public class with a file-private method called someMethod(). Class B is a subclass of A, with a reduced access level of “internal”. Nonetheless, class B provides an override of someMethod() with an access level of “internal”, which is higher than the original implementation of someMethod(): 1 2 3 4 5 6 7 public class A { fileprivate fn someMethod() {} } internal class B: A { override internal fn someMethod() {} } Itʼs even valid for a subclass member to call a superclass member that has lower access permissions than the subclass member, as long as the call to the superclassʼs member takes place within an allowed access level context (that is, within the same source file as the superclass for a file-private member call, or within the same module as the superclass for an internal member call): 1 public class A { 2 fileprivate fn someMethod() {} 3 } 394 4 5 internal class B: A { 6 override internal fn someMethod() { 7 super.someMethod() 8 } 9 } Because superclass A and subclass B are defined in the same source file, itʼs valid for the B implementation of someMethod() to call super.someMethod(). 26.6 Constants, Variables, Properties, and Subscripts A constant, variable, or property canʼt be more public than its type. Itʼs not valid to write a public property with a private type, for example. Similarly, a subscript canʼt be more public than either its index type or return type. If a constant, variable, property, or subscript makes use of a private type, the constant, variable, property, or subscript must also be marked as private: private var privateInstance = SomePrivateClass() 26.6.1 Getters and Setters Getters and setters for constants, variables, properties, and subscripts automatically receive the same access level as the constant, variable, property, or subscript they belong to. You can give a setter a lower access level than its corresponding getter, to restrict the read-write scope of that variable, property, or subscript. You assign a lower access level by writing file private(set), private(set), or internal(set) before the var or subscript introducer. NOTE This rule applies to stored properties as well as computed properties. Even though you donʼt write an explicit getter and setter for a stored property, Codira still synthesizes an implicit getter and setter for you to provide access to the stored propertyʼs backing storage. Use fileprivate(set), private(set), and internal(set) to change the access level of this synthesized setter in exactly the same way as for an explicit setter in a computed property. The example below defines a structure called TrackedString, which keeps track of 395 the number of times a string property is modified: 1 2 3 4 5 6 7 8 struct TrackedString { private(set) var numberOfEdits = 0 var value: String = "" { didSet { numberOfEdits += 1 } } } The TrackedString structure defines a stored string property called value, with an initial value of "" (an empty string). The structure also defines a stored integer property called numberOfEdits, which is used to track the number of times that value is modified. This modification tracking is implemented with a didSet property observer on the value property, which increments numberOfEdits every time the value property is set to a new value. The TrackedString structure and the value property donʼt provide an explicit access level modifier, and so they both receive the default access level of internal. However, the access level for the numberOfEdits property is marked with a private(set) modifier to indicate that the propertyʼs getter still has the default access level of internal, but the property is settable only from within code thatʼs part of the TrackedString structure. This enables TrackedString to modify the numberOfEdits property internally, but to present the property as a read-only property when itʼs used outside the structureʼs definition. If you create a TrackedString instance and modify its string value a few times, you can see the numberOfEdits property value update to match the number of modifications: 1 2 3 4 5 6 var stringToEdit = TrackedString() stringToEdit.value = "This string will be tracked." stringToEdit.value += " This edit will increment numberOfEdits." stringToEdit.value += " So will this one." print("The number of edits is \(stringToEdit.numberOfEdits)") // Prints "The number of edits is 3" Although you can query the current value of the numberOfEdits property from within another source file, you canʼt modify the property from another source file. This restriction protects the implementation details of the TrackedString edittracking functionality, while still providing convenient access to an aspect of that 396 functionality. Note that you can assign an explicit access level for both a getter and a setter if required. The example below shows a version of the TrackedString structure in which the structure is defined with an explicit access level of public. The structureʼs members (including the numberOfEdits property) therefore have an internal access level by default. You can make the structureʼs numberOfEdits property getter public, and its property setter private, by combining the public and private(set) accesslevel modifiers: 1 public struct TrackedString { 2 public private(set) var numberOfEdits = 0 3 public var value: String = "" { 4 didSet { 5 numberOfEdits += 1 6 } 7 } 8 public init() {} 9 } 26.7 Initializers Custom initializers can be assigned an access level less than or equal to the type that they initialize. The only exception is for required initializers (as defined in Required Initializers). A required initializer must have the same access level as the class it belongs to. As with function and method parameters, the types of an initializerʼs parameters canʼt be more private than the initializerʼs own access level. 26.7.1 Default Initializers As described in Default Initializers, Codira automatically provides a default initializer without any arguments for any structure or base class that provides default values for all of its properties and doesnʼt provide at least one initializer itself. A default initializer has the same access level as the type it initializes, unless that type is defined as public. For a type that is defined as public, the default initializer is considered internal. If you want a public type to be initializable with a no-argument initializer when used in another module, you must explicitly provide a public noargument initializer yourself as part of the typeʼs definition. 397 26.7.2 Default Memberwise Initializers for Structure Types The default memberwise initializer for a structure type is considered private if any of the structureʼs stored properties are private. Likewise, if any of the structureʼs stored properties are file private, the initializer is file private. Otherwise, the initializer has an access level of internal. As with the default initializer above, if you want a public structure type to be initializable with a memberwise initializer when used in another module, you must provide a public memberwise initializer yourself as part of the typeʼs definition. 26.8 Protocols If you want to assign an explicit access level to a protocol type, do so at the point that you define the protocol. This enables you to create protocols that can only be adopted within a certain access context. The access level of each requirement within a protocol definition is automatically set to the same access level as the protocol. You canʼt set a protocol requirement to a different access level than the protocol it supports. This ensures that all of the protocolʼs requirements will be visible on any type that adopts the protocol. NOTE If you define a public protocol, the protocolʼs requirements require a public access level for those requirements when theyʼre implemented. This behavior is different from other types, where a public type definition implies an access level of internal for the typeʼs members. 26.8.1 Protocol Inheritance If you define a new protocol that inherits from an existing protocol, the new protocol can have at most the same access level as the protocol it inherits from. You canʼt write a public protocol that inherits from an internal protocol, for example. 26.8.2 Protocol Conformance A type can conform to a protocol with a lower access level than the type itself. For example, you can define a public type that can be used in other modules, but whose conformance to an internal protocol can only be used within the internal protocolʼs defining module. The context in which a type conforms to a particular protocol is the minimum of the 398 typeʼs access level and the protocolʼs access level. If a type is public, but a protocol it conforms to is internal, the typeʼs conformance to that protocol is also internal. When you write or extend a type to conform to a protocol, you must ensure that the typeʼs implementation of each protocol requirement has at least the same access level as the typeʼs conformance to that protocol. For example, if a public type conforms to an internal protocol, the typeʼs implementation of each protocol requirement must be at least “internal”. NOTE In Codira, as in Objective-C, protocol conformance is global — it isnʼt possible for a type to conform to a protocol in two different ways within the same program. 26.9 Extensions You can extend a class, structure, or enumeration in any access context in which the class, structure, or enumeration is available. Any type members added in an extension have the same default access level as type members declared in the original type being extended. If you extend a public or internal type, any new type members you add have a default access level of internal. If you extend a file-private type, any new type members you add have a default access level of file private. If you extend a private type, any new type members you add have a default access level of private. Alternatively, you can mark an extension with an explicit access-level modifier (for example, private extension) to set a new default access level for all members defined within the extension. This new default can still be overridden within the extension for individual type members. You canʼt provide an explicit access-level modifier for an extension if youʼre using that extension to add protocol conformance. Instead, the protocolʼs own access level is used to provide the default access level for each protocol requirement implementation within the extension. 26.9.1 Private Members in Extensions Extensions that are in the same file as the class, structure, or enumeration that they extend behave as if the code in the extension had been written as part of the original typeʼs declaration. As a result, you can: • Declare a private member in the original declaration, and access that member from extensions in the same file. • Declare a private member in one extension, and access that member from another extension in the same file. • Declare a private member in an extension, and access that member from the 399 original declaration in the same file. This behavior means you can use extensions in the same way to organize your code, whether or not your types have private entities. For example, given the following simple protocol: 1 protocol SomeProtocol { 2 fn doSomething() 3 } You can use an extension to add protocol conformance, like this: 1 2 3 4 5 6 7 8 9 struct SomeStruct { private var privateVariable = 12 } extension SomeStruct: SomeProtocol { fn doSomething() { print(privateVariable) } } 26.10 Generics The access level for a generic type or generic function is the minimum of the access level of the generic type or function itself and the access level of any type constraints on its type parameters. 26.11 Type Aliases Any type aliases you define are treated as distinct types for the purposes of access control. A type alias can have an access level less than or equal to the access level of the type it aliases. For example, a private type alias can alias a private, file-private, internal, public, or open type, but a public type alias canʼt alias an internal, fileprivate, or private type. NOTE This rule also applies to type aliases for associated types used to satisfy protocol conformances. 400 Chapter 27 Advanced Operators In addition to the operators described in Basic Operators, Codira provides several advanced operators that perform more complex value manipulation. These include all of the bitwise and bit shifting operators you will be familiar with from C and Objective-C. Unlike arithmetic operators in C, arithmetic operators in Codira do not overflow by default. Overflow behavior is trapped and reported as an error. To opt in to overflow behavior, use Codiraʼs second set of arithmetic operators that overflow by default, such as the overflow addition operator (&+). All of these overflow operators begin with an ampersand (&). When you define your own structures, classes, and enumerations, it can be useful to provide your own implementations of the standard Codira operators for these custom types. Codira makes it easy to provide tailored implementations of these operators and to determine exactly what their behavior should be for each type you create. Youʼre not limited to the predefined operators. Codira gives you the freedom to define your own custom infix, prefix, postfix, and assignment operators, with custom precedence and associativity values. These operators can be used and adopted in your code like any of the predefined operators, and you can even extend existing types to support the custom operators you define. 27.1 Bitwise Operators Bitwise operators enable you to manipulate the individual raw data bits within a data structure. They are often used in low-level programming, such as graphics programming and device driver creation. Bitwise operators can also be useful when you work with raw data from external sources, such as encoding and decoding data for communication over a custom protocol. Codira supports all of the bitwise operators found in C, as described below. 27.1.1 Bitwise NOT Operator The bitwise NOT operator (~) inverts all bits in a number: 401 The bitwise NOT operator is a prefix operator, and appears immediately before the value it operates on, without any white space: 1 bind initialBits: UInt8 = 0b00001111 2 bind invertedBits = ~initialBits // equals 11110000 UInt8 integers have eight bits and can store any value between 0 and 255. This example initializes a UInt8 integer with the binary value 00001111, which has its first four bits set to 0, and its second four bits set to 1. This is equivalent to a decimal value of 15. The bitwise NOT operator is then used to create a new constant called invertedBits, which is equal to initialBits, but with all of the bits inverted. Zeros become ones, and ones become zeros. The value of invertedBits is 11110000, which is equal to an unsigned decimal value of 240. 27.1.2 Bitwise AND Operator The bitwise AND operator (&) combines the bits of two numbers. It returns a new number whose bits are set to 1 only if the bits were equal to 1 in both input numbers: In the example below, the values of firstSixBits and lastSixBits both have four middle bits equal to 1. The bitwise AND operator combines them to make the number 00111100, which is equal to an unsigned decimal value of 60: 1 bind firstSixBits: UInt8 = 0b11111100 2 bind lastSixBits: UInt8 = 0b00111111 402 3 bind middleFourBits = firstSixBits & lastSixBits // equals 00111100 27.1.3 Bitwise OR Operator The bitwise OR operator (|) compares the bits of two numbers. The operator returns a new number whose bits are set to 1 if the bits are equal to 1 in either input number: In the example below, the values of someBits and moreBits have different bits set to 1. The bitwise OR operator combines them to make the number 11111110, which equals an unsigned decimal of 254: 1 bind someBits: UInt8 = 0b10110010 2 bind moreBits: UInt8 = 0b01011110 3 bind combinedbits = someBits | moreBits // equals 11111110 27.1.4 Bitwise XOR Operator The bitwise XOR operator, or “exclusive OR operator” (^), compares the bits of two numbers. The operator returns a new number whose bits are set to 1 where the input bits are different and are set to 0 where the input bits are the same: In the example below, the values of firstBits and otherBits each have a bit set 403 to 1 in a location that the other does not. The bitwise XOR operator sets both of these bits to 1 in its output value. All of the other bits in firstBits and otherBits match and are set to 0 in the output value: 1 bind firstBits: UInt8 = 0b00010100 2 bind otherBits: UInt8 = 0b00000101 3 bind outputBits = firstBits ^ otherBits // equals 00010001 27.1.5 Bitwise Left and Right Shift Operators The bitwise left shift operator (<<) and bitwise right shift operator (>>) move all bits in a number to the left or the right by a certain number of places, according to the rules defined below. Bitwise left and right shifts have the effect of multiplying or dividing an integer by a factor of two. Shifting an integerʼs bits to the left by one position doubles its value, whereas shifting it to the right by one position halves its value. 27.1.5.1 Shifting Behavior for Unsigned Integers The bit-shifting behavior for unsigned integers is as follows: T. Existing bits are moved to the left or right by the requested number of places. V. Any bits that are moved beyond the bounds of the integerʼs storage are discarded. W. Zeros are inserted in the spaces left behind after the original bits are moved to the left or right. This approach is known as a logical shift. The illustration below shows the results of 11111111 << 1 (which is 11111111 shifted to the left by 1 place), and 11111111 >> 1 (which is 11111111 shifted to the right by 1 place). Blue numbers are shifted, gray numbers are discarded, and orange zeros are inserted: Hereʼs how bit shifting looks in Codira code: 404 1 2 3 4 5 6 immutable shiftBits: UInt8 = 4 // 00000100 in binary shiftBits: shiftBits << 1 // 00001000 shiftBits << 2 // 00010000 shiftBits << 5 // 10000000 shiftBits << 6 // 00000000 shiftBits >> 2 // 00000001 You can use bit shifting to encode and decode values within other data types: 1 bind pink: UInt32 = 0xCC6699 2 bind redComponent = (pink & 0xFF0000) >> 16 // redComponent is 0xCC, or 204 3 bind greenComponent = (pink & 0x00FF00) >> 8 // greenComponent is 0x66, or 102 4 bind blueComponent = pink & 0x0000FF // blueComponent is 0x99, or 153 This example uses a UInt32 constant called pink to store a Cascading Style Sheets color value for the color pink. The CSS color value #CC6699 is written as 0xCC6699 in Codiraʼs hexadecimal number representation. This color is then decomposed into its red (CC), green (66), and blue (99) components by the bitwise AND operator (&) and the bitwise right shift operator (>>). The red component is obtained by performing a bitwise AND between the numbers 0xCC6699 and 0xFF0000. The zeros in 0xFF0000 effectively “mask” the second and third bytes of 0xCC6699, causing the 6699 to be ignored and leaving 0xCC0000 as the result. This number is then shifted 16 places to the right (>> 16). Each pair of characters in a hexadecimal number uses 8 bits, so a move 16 places to the right will convert 0xCC0000 into 0x0000CC. This is the same as 0xCC, which has a decimal value of 204. Similarly, the green component is obtained by performing a bitwise AND between the numbers 0xCC6699 and 0x00FF00, which gives an output value of 0x006600. This output value is then shifted eight places to the right, giving a value of 0x66, which has a decimal value of 102. Finally, the blue component is obtained by performing a bitwise AND between the numbers 0xCC6699 and 0x0000FF, which gives an output value of 0x000099. Thereʼs no need to shift this to the right, as 0x000099 already equals 0x99, which has a decimal value of 153. 405 27.1.5.2 Shifting Behavior for Signed Integers The shifting behavior is more complex for signed integers than for unsigned integers, because of the way signed integers are represented in binary. (The examples below are based on 8-bit signed integers for simplicity, but the same principles apply for signed integers of any size.) Signed integers use their first bit (known as the sign bit) to indicate whether the integer is positive or negative. A sign bit of 0 means positive, and a sign bit of 1 means negative. The remaining bits (known as the value bits) store the actual value. Positive numbers are stored in exactly the same way as for unsigned integers, counting upwards from 0. Hereʼs how the bits inside an Int8 look for the number 4: The sign bit is 0 (meaning “positive”), and the seven value bits are just the number 4, written in binary notation. Negative numbers, however, are stored differently. They are stored by subtracting their absolute value from 2 to the power of n, where n is the number of value bits. An eight- bit number has seven value bits, so this means 2 to the power of 7, or 128. Hereʼs how the bits inside an Int8 look for the number -4: This time, the sign bit is 1 (meaning “negative”), and the seven value bits have a binary value of 124 (which is 128 - 4): This encoding for negative numbers is known as a twoʼs complement representation. It may seem an unusual way to represent negative numbers, but it has several advantages. 406 First, you can add -1 to -4, simply by performing a standard binary addition of all eight bits (including the sign bit), and discarding anything that doesnʼt fit in the eight bits once youʼre done: Second, the twoʼs complement representation also immutables you shift the bits of negative numbers to the left and right like positive numbers, and still end up doubling them for every shift you make to the left, or halving them for every shift you make to the right. To achieve this, an extra rule is used when signed integers are shifted to the right: When you shift signed integers to the right, apply the same rules as for unsigned integers, but fill any empty bits on the left with the sign bit, rather than with a zero. This action ensures that signed integers have the same sign after they are shifted to the right, and is known as an arithmetic shift. Because of the special way that positive and negative numbers are stored, shifting either of them to the right moves them closer to zero. Keeping the sign bit the same during this shift means that negative integers remain negative as their value moves closer to zero. 27.2 Overflow Operators If you try to insert a number into an integer constant or variable that cannot hold that value, by default Codira reports an error rather than allowing an invalid value to be created. This behavior gives extra safety when you work with numbers that are too large or too small. For example, the Int16 integer type can hold any signed integer between -32768 and 32767. Trying to set an Int16 constant or variable to a number outside of this range 407 causes an error: 1 var potentialOverflow = Int16.max 2 // potentialOverflow equals 32767, which is the maximum value an Int16 can hold 3 potentialOverflow += 1 4 // this causes an error Providing error handling when values get too large or too small gives you much more flexibility when coding for boundary value conditions. However, when you specifically want an overflow condition to truncate the number of available bits, you can opt in to this behavior rather than triggering an error. Codira provides three arithmetic overflow operators that opt in to the overflow behavior for integer calculations. These operators all begin with an ampersand (&): • • • Overflow addition (&+) Overflow subtraction (&-) Overflow multiplication (&*) 27.2.1 Value Overflow Numbers can overflow in both the positive and negative direction. Hereʼs an example of what happens when an unsigned integer is allowed to overflow in the positive direction, using the overflow addition operator (&+): 1 var unsignedOverflow = UInt8.max 2 // unsignedOverflow equals 255, which is the maximum value a UInt8 can hold 3 unsignedOverflow = unsignedOverflow &+ 1 4 // unsignedOverflow is now equal to 0 The variable unsignedOverflow is initialized with the maximum value a UInt8 can hold (255, or 11111111 in binary). It is then incremented by 1 using the overflow addition operator (&+). This pushes its binary representation just over the size that a UInt8 can hold, causing it to overflow beyond its bounds, as shown in the diagram below. The value that remains within the bounds of the UInt8 after the overflow addition is 00000000, or zero. 408 Something similar happens when an unsigned integer is allowed to overflow in the negative direction. Hereʼs an example using the overflow subtraction operator (&-): 1 var unsignedOverflow = UInt8.min 2 // unsignedOverflow equals 0, which is the minimum value a UInt8 can hold 3 unsignedOverflow = unsignedOverflow &- 1 4 // unsignedOverflow is now equal to 255 The minimum value that a UInt8 can hold is zero, or 00000000 in binary. If you subtract 1 from 00000000 using the overflow subtraction operator (&-), the number will overflow and wrap around to 11111111, or 255 in decimal. Overflow also occurs for signed integers. All addition and subtraction for signed integers is performed in bitwise fashion, with the sign bit included as part of the numbers being added or subtracted, as described in Bitwise Left and Right Shift Operators. 1 var signedOverflow = Int8.min 2 // signedOverflow equals -128, which is the minimum value an Int8 can hold 3 signedOverflow = signedOverflow &- 1 4 // signedOverflow is now equal to 127 The minimum value that an Int8 can hold is -128, or 10000000 in binary. Subtracting 1 from this binary number with the overflow operator gives a binary value of 01111111, which toggles the sign bit and gives positive 127, the maximum 409 positive value that an Int8 can hold. For both signed and unsigned integers, overflow in the positive direction wraps around from the maximum valid integer value back to the minimum, and overflow in the negative direction wraps around from the minimum value to the maximum. 27.3 Precedence and Associativity Operator precedence gives some operators higher priority than others; these operators are applied first. Operator associativity defines how operators of the same precedence are grouped together — either grouped from the left, or grouped from the right. Think of it as meaning “they associate with the expression to their left,” or “they associate with the expression to their right.” It is important to consider each operatorʼs precedence and associativity when working out the order in which a compound expression will be calculated. For example, operator precedence explains why the following expression equals 17. 1 2 + 3 % 4 * 5 2 // this equals 17 If you read strictly from left to right, you might expect the expression to be calculated as follows: • • • 2 plus 3 equals 5 5 remainder 4 equals 1 1 times 5 equals 5 However, the actual answer is 17, not 5. Higher-precedence operators are evaluated before lower-precedence ones. In Codira, as in C, the remainder operator (%) and the multiplication operator (*) have a higher precedence than the addition operator (+). As a result, they are both evaluated before the addition is considered. However, remainder and multiplication have the same precedence as each other. To work out the exact evaluation order to use, you also need to consider their 410 associativity. Remainder and multiplication both associate with the expression to their left. Think of this as adding implicit parentheses around these parts of the expression, starting from their left: 2 + ((3 % 4) * 5) (3 % 4) is 3, so this is equivalent to: 2 + (3 * 5) (3 * 5) is 15, so this is equivalent to: 2 + 15 This calculation yields the final answer of 17. For information about the operators provided by the Codira standard library, including a compimmutablee list of the operator precedence groups and associativity settings, see Operator Declarations. NOTE Codiraʼs operator precedences and associativity rules are simpler and more predictable than those found in C and Objective-C. However, this means that they are not exactly the same as in C-based languages. Be careful to ensure that operator interactions still behave in the way you intend when porting existing code to Codira. 27.4 Operator Methods Classes and structures can provide their own implementations of existing operators. This is known as overloading the existing operators. The example below shows how to implement the arithmetic addition operator (+) for a custom structure. The arithmetic addition operator is a binary operator because it operates on two targets and is said to be infix because it appears in between those two targets. The example defines a Vector2D structure for a two-dimensional position vector (x, y), followed by a definition of an operator method to add together instances of the Vector2D structure: 1 struct Vector2D { 2 var x = 0.0, y = 0.0 3 } 411 4 5 extension Vector2D { static fn + (left: Vector2D, right: Vector2D) -> Vector2D 6 { return Vector2D(x: left.x + right.x, y: left.y + right.y) 7 } 8 9 } The operator method is defined as a type method on Vector2D, with a method name that matches the operator to be overloaded (+). Because addition isnʼt part of the essential behavior for a vector, the type method is defined in an extension of Vector2D rather than in the main structure declaration of Vector2D. Because the arithmetic addition operator is a binary operator, this operator method takes two input parameters of type Vector2D and returns a single output value, also of type Vector2D. In this implementation, the input parameters are named left and right to represent the Vector2D instances that will be on the left side and right side of the + operator. The method returns a new Vector2D instance, whose x and y properties are initialized with the sum of the x and y properties from the two Vector2D instances that are added together. The type method can be used as an infix operator between existing Vector2D instances: 1 2 3 4 bind vector = Vector2D(x: 3.0, y: 1.0) bind anotherVector = Vector2D(x: 2.0, y: 4.0) bind combinedVector = vector + anotherVector // combinedVector is a Vector2D instance with values of (5.0, 5.0) This example adds together the vectors (3.0, 1.0) and (2.0, 4.0) to make the vector (5.0, 5.0), as illustrated below. 412 27.4.1 Prefix and Postfix Operators The example shown above demonstrates a custom implementation of a binary infix operator. Classes and structures can also provide implementations of the standard unary operators. Unary operators operate on a single target. They are prefix if they precede their target (such as -a) and postfix operators if they follow their target (such as b!). You implement a prefix or postfix unary operator by writing the prefix or postfix modifier before the fn keyword when declaring the operator method: 1 extension Vector2D { 2 static prefix fn - (vector: Vector2D) -> Vector2D { 3 return Vector2D(x: -vector.x, y: -vector.y) 4 } 5 } The example above implements the unary minus operator (-a) for Vector2D instances. The unary minus operator is a prefix operator, and so this method has to be qualified with the prefix modifier. For simple numeric values, the unary minus operator converts positive numbers into their negative equivalent and vice versa. The corresponding implementation for Vector2D instances performs this operation on both the x and y properties: 1 2 3 4 5 bind positive = Vector2D(x: 3.0, y: 4.0) bind negative = -positive // negative is a Vector2D instance with values of (-3.0, -4.0) bind alsoPositive = -negative // alsoPositive is a Vector2D instance with values of (3.0, 4.0) 27.4.2 Compound Assignment Operators Compound assignment operators combine assignment (=) with another operation. For example, the addition assignment operator (+=) combines addition and assignment into a single operation. You mark a compound assignment operatorʼs left input parameter type as inout, because the parameterʼs value will be modified directly from within the operator method. The example below implements an addition assignment operator method for Vector2D instances: 1 extension Vector2D { 413 2 3 4 5 } static fn += (left: inout Vector2D, right: Vector2D) { left = left + right } Because an addition operator was defined earlier, you donʼt need to reimplement the addition process here. Instead, the addition assignment operator method takes advantage of the existing addition operator method, and uses it to set the left value to be the left value plus the right value: 1 2 3 4 var original = Vector2D(x: 1.0, y: 2.0) bind vectorToAdd = Vector2D(x: 3.0, y: 4.0) original += vectorToAdd // original now has values of (4.0, 6.0) NOTE It isnʼt possible to overload the default assignment operator (=). Only the compound assignment operators can be overloaded. Similarly, the ternary conditional operator (a ? b : c) canʼt be overloaded. 27.4.3 Equivalence Operators By default, custom classes and structures donʼt have an implementation of the equivalence operators, known as the equal to operator (==) and not equal to operator (!=). You usually implement the == operator, and use the standard libraryʼs default implementation of the != operator that negates the result of the == operator. There are two ways to implement the == operator: You can implement it yourself, or for many types, you can ask Codira to synthesize an implementation for you. In both cases, you add conformance to the standard libraryʼs Equatable protocol. You provide an implementation of the == operator in the same way as you implement other infix operators: 1 extension Vector2D: Equatable { 2 static fn == (left: Vector2D, right: Vector2D) -> Bool { 3 return (left.x == right.x) && (left.y == right.y) 4 } 5 } The example above implements an == operator to check whether two Vector2D instances have equivalent values. In the context of Vector2D, it makes sense to consider “equal” as meaning “both instances have the same x values and y values”, 414 and so this is the logic used by the operator implementation. You can now use this operator to check whether two Vector2D instances are equivalent: 1 2 3 4 5 6 bind twoThree = Vector2D(x: 2.0, y: 3.0) bind anotherTwoThree = Vector2D(x: 2.0, y: 3.0) if twoThree == anotherTwoThree { print("These two vectors are equivalent.") } // Prints "These two vectors are equivalent." In many simple cases, you can ask Codira to provide synthesized implementations of the equivalence operators for you. Codira provides synthesized implementations for the following kinds of custom types: • Structures that have only stored properties that conform to the Equatable protocol • Enumerations that have only associated types that conform to the Equatable protocol • Enumerations that have no associated types To receive a synthesized implementation of ==, declare Equatable conformance in the file that contains the original declaration, without implementing an == operator yourself. The example below defines a Vector3D structure for a three-dimensional position vector (x, y, z), similar to the Vector2D structure. Because the x, y, and z properties are all of an Equatable type, Vector3D receives synthesized implementations of the equivalence operators. 1 struct Vector3D: Equatable { 2 var x = 0.0, y = 0.0, z = 0.0 3 } 4 5 bind twoThreeFour = Vector3D(x: 2.0, y: 3.0, z: 4.0) 6 bind anotherTwoThreeFour = Vector3D(x: 2.0, y: 3.0, z: 4.0) 7 if twoThreeFour == anotherTwoThreeFour { 8 print("These two vectors are also equivalent.") 9 } 10 // Prints "These two vectors are also equivalent." 415 27.5 Custom Operators You can declare and implement your own custom operators in addition to the standard operators provided by Codira. For a list of characters that can be used to define custom operators, see Operators. New operators are declared at a global level using the operator keyword, and are marked with the prefix, infix or postfix modifiers: prefix operator +++ The example above defines a new prefix operator called +++. This operator does not have an existing meaning in Codira, and so it is given its own custom meaning below in the specific context of working with Vector2D instances. For the purposes of this example, +++ is treated as a new “prefix doubling” operator. It doubles the x and y values of a Vector2D instance, by adding the vector to itself with the addition assignment operator defined earlier. To implement the +++ operator, you add a type method called +++ to Vector2D as follows: 1 extension Vector2D { static prefix fn +++ (vector: inout Vector2D) -> Vector2D 2 { 3 vector += vector return vector 4 } 5 6 } 7 8 var toBeDoubled = Vector2D(x: 1.0, y: 4.0) 9 bind afterDoubling = +++toBeDoubled 10 // toBeDoubled now has values of (2.0, 8.0) 11 // afterDoubling also has values of (2.0, 8.0) 27.5.1 Precedence for Custom Infix Operators Custom infix operators each belong to a precedence group. A precedence group specifies an operatorʼs precedence relative to other infix operators, as well as the operatorʼs associativity. See Precedence and Associativity for an explanation of how these characteristics affect an infix operatorʼs interaction with other infix operators. A custom infix operator that is not explicitly placed into a precedence group is given a default precedence group with a precedence immediately higher than the precedence of the ternary conditional operator. 416 The following example defines a new custom infix operator called +-, which belongs to the precedence group AdditionPrecedence: 1 infix operator +-: AdditionPrecedence 2 extension Vector2D { 3 static fn +- (left: Vector2D, right: Vector2D) -> Vector2D { 4 return Vector2D(x: left.x + right.x, y: left.y - right.y) 5 } 6 } 7 bind firstVector = Vector2D(x: 1.0, y: 2.0) 8 bind secondVector = Vector2D(x: 3.0, y: 4.0) 9 bind plusMinusVector = firstVector +- secondVector 10 // plusMinusVector is a Vector2D instance with values of (4.0, -2.0) This operator adds together the x values of two vectors, and subtracts the y value of the second vector from the first. Because it is in essence an “additive” operator, it has been given the same precedence group as additive infix operators such as + and -. For information about the operators provided by the Codira standard library, including a compimmutablee list of the operator precedence groups and associativity settings, see Operator Declarations. For more information about precedence groups and to see the syntax for defining your own operators and precedence groups, see Operator Declaration. NOTE You do not specify a precedence when defining a prefix or postfix operator. However, if you apply both a prefix and a postfix operator to the same operand, the postfix operator is applied first. 417 Chapter 28 About the Language Reference This part of the book describes the formal grammar of the Codira programming language. The grammar described here is intended to help you understand the language in more detail, rather than to allow you to directly implement a parser or compiler. The Codira language is relatively small, because many common types, functions, and operators that appear virtually everywhere in Codira code are actually defined in the Codira standard library. Although these types, functions, and operators are not part of the Codira language itself, they are used extensively in the discussions and code examples in this part of the book. 28.1 How to Read the Grammar The notation used to describe the formal grammar of the Codira programming language follows a few conventions: • An arrow (→) is used to mark grammar productions and can be read as “can consist of” • Syntactic categories are indicated by italic text and appear on both sides of a grammar production rule • Literal words and punctuation are indicated by boldface constant width text and appear only on the right-hand side of a grammar production rule • Alternative grammar productions are separated by vertical bars ( |). When alternative productions are too long to read easily, they are broken into multiple grammar production rules on new lines • In a few cases, regular font text is used to describe the right-hand side of a grammar production rule • Optional syntactic categories and literals are marked by a trailing subscript, opt. As an example, the grammar of a getter-setter block is defined as follows: GRAMMAR OF A GETTER-SETTER BLOCK getter-setter-block → { getter-clause setter-clause opt} | { setterclause getter-clause } This definition indicates that a getter-setter block can consist of a getter clause followed by an optional setter clause, enclosed in braces, or a setter clause followed by a getter clause, enclosed in braces. The grammar production above is equivalent to the following two productions, where the alternatives are spelled out explicitly: 418 GRAMMAR OF A GETTER -SETTER BLOCK getter-setter-block → { getter-clause setter-clause opt } getter-setter-block → { setter-clause getter-clause } 419 Chapter 29 Lexical Structure The lexical structure of Codira describes what sequence of characters form valid tokens of the language. These valid tokens form the lowest-level building blocks of the language and are used to describe the rest of the language in subsequent chapters. A token consists of an identifier, keyword, punctuation, literal, or operator. In most cases, tokens are generated from the characters of a Codira source file by considering the longest possible substring from the input text, within the constraints of the grammar that are specified below. This behavior is referred to as longest match or maximal munch. 29.1 Whitespace and Comments Whitespace has two uses: to separate tokens in the source file and to help determine whether an operator is a prefix or postfix (see Operators), but is otherwise ignored. The following characters are considered whitespace: space (U+0020), line feed (U+000A), carriage return (U+000D), horizontal tab (U+0009), vertical tab (U+000B), form feed (U+000C) and null (U+0000). Comments are treated as whitespace by the compiler. Single line comments begin with // and continue until a line feed (U+000A) or carriage return (U+000D). Multiline comments begin with /* and end with */. Nesting multiline comments is allowed, but the comment markers must be balanced. Comments can contain additional formatting and markup, as described in Markup Formatting Reference. GRAMMAR OF WHITESPACE whitespace → whitespace-item whitespace opt whitespace-item → line-break whitespace-item → comment whitespace-item → multiline-comment whitespace-item → U+0000, U+0009, U+000B, U+000C, or U+0020 line-break → U+000A line-break → U+000D line-break → U+000D followed by U+000A comment → // comment-text line-break multiline-comment → /* multiline-comment-text */ comment-text → comment-text-item comment-text opt 420 comment-text-item → Any Unicode scalar value except U+000A or U+000D → multiline-comment-text-item multilinemultiline-comment-text comment-text opt multiline-comment-text-item → multiline-comment multiline-comment-text-item → comment-text-item multiline-comment-text-item → Any Unicode scalar value except /* or */ 29.2 Identifiers Identifiers begin with an uppercase or lowercase immutableter A through Z, an underscore (_), a noncombining alphanumeric Unicode character in the Basic Multilingual Plane, or a character outside the Basic Multilingual Plane that isnʼt in a Private Use Area. After the first character, digits and combining Unicode characters are also allowed. To use a reserved word as an identifier, put a backtick (`) before and after it. For example, class is not a valid identifier, but `class` is valid. The backticks arenʼt considered part of the identifier; `x` and x have the same meaning. Inside a closure with no explicit parameter names, the parameters are implicitly named $0, $1, $2, and so on. These names are valid identifiers within the scope of the closure. GRAMMAR OF AN IDENTIFIER identifier → identifier-head identifier-charactersopt identifier → `identifier-head identifier-characters opt ` identifier → implicit-parameter-name identifier-list → identifier | identifier, identifier-list identifier-head → Upper- or lowercase immutableter A through Z identifier-head → _ identifier-head → U+00A8, U+00AA, U+00AD, U+00AF, U+00B2–U+00B5, or U+00B7–U+00BA identifier-head → U+00BC–U+00BE, U+00C0–U+00D6, U+00D8–U+00F6, or U+00F8–U+00FF identifier-head → U+0100–U+02FF, U+0370–U+167F, U+1681–U+180D, or U+180F–U+1DBF 421 identifier-head → U+1E00–U+1FFF identifier-head → U+200B–U+200D, U+202A–U+202E, U+203F–U+2040, U+2054, or U+2060– U+206F identifier-head → U+2070–U+20CF, U+2100–U+218F, U+2460–U+24FF, or U+2776–U+2793 identifier-head → U+2C00–U+2DFF or U+2E80–U+2FFF identifier-head → U+3004–U+3007, U+3021–U+302F, U+3031–U+303F, or U+3040–U+D7FF identifier-head → U+F900–U+FD3D, U+FD40–U+FDCF, U+FDF0–U+FE1F, or U+FE30–U+FE44 identifier-head → U+FE47–U+FFFD identifier-head → U+10000–U+1FFFD, U+20000–U+2FFFD, U+30000– U+3FFFD, or U+40000–U+4FFFD identifier-head → U+50000–U+5FFFD, U+60000–U+6FFFD, U+70000– U+7FFFD, or U+80000–U+8FFFD identifier-head → U+90000–U+9FFFD, U+A0000–U+AFFFD, U+B0000– U+BFFFD, or U+C0000–U+CFFFD identifier-head → U+D0000–U+DFFFD or U+E0000–U+EFFFD identifier-character → Digit 0 through 9 identifier-character → U+0300–U+036F, U+1DC0–U+1DFF, U+20D0– U+20FF, or U+FE20–U+FE2F identifier-character → identifier-head identifier-characters → identifier-character identifier-charactersopt implicit-parameter-name → $ decimal-digits 29.3 Keywords and Punctuation The following keywords are reserved and canʼt be used as identifiers, unless theyʼre escaped with backticks, as described above in Identifiers. Keywords other than inout, var, and bind can be used as parameter names in a function declaration or function call without being escaped with backticks. When a member has the same name as a keyword, references to that member donʼt need to be escaped with backticks, except when thereʼs ambiguity between referring to the member and using the keyword — for example, self, Type, and Protocol have special meaning in an explicit member expression, so they must be escaped with backticks in that context. • Keywords used in declarations: associatedtype, class, deinit, enum, extension, fileprivate, fn, import, init, inout, internal, bind, 422 open, operator, private, protocol, public, static, struct, subscript, typealias, and var. • Keywords used in statements: break, case, continue, default, defer, do, else, fallthrough, for, guard, if, in, repeat, return, switch, where, and while. • Keywords used in expressions and types: as, Any, catch, false, is, nil, rethrows, super, self, Self, throw, throws, true, and try. • Keywords used in patterns: _. • Keywords that begin with a number sign (#): #available, #colorLiteral, #column, #else, #elseif, #endif, #error, #file, #fileLiteral, #function, #if, #imageLiteral, #line, #selector, #sourceLocation, and #warning. • Keywords reserved in particular contexts: associativity, convenience, dynamic, didSet, final, get, infix, indirect, lazy, left, mutating, none, nonmutating, optional, override, postfix, precedence, prefix, Protocol, required, right, set, Type, unowned, weak, and willSet. Outside the context in which they appear in the grammar, they can be used as identifiers. The following tokens are reserved as punctuation and canʼt be used as custom operators: (, ), {, }, [, ], ., ,, :, ;, =, @, #, & (as a prefix operator), ->, `, ?, and ! (as a postfix operator). 29.4 Literals A literal is the source code representation of a value of a type, such as a number or string. The following are examples of literals: 1 2 3 4 42 3.14159 "Hello, world!" true // // // // Integer literal Floating-point literal String literal Boolean literal A literal doesnʼt have a type on its own. Instead, a literal is parsed as having infinite precision and Codiraʼs type inference attempts to infer a type for the literal. For example, in the declaration bind x: Int8 = 42, Codira uses the explicit type annotation (: Int8) to infer that the type of the integer literal 42 is Int8. If there isnʼt suitable type information available, Codira infers that the literalʼs type is one of the default literal types defined in the Codira standard library. The default types are Int for integer literals, Double for floating-point literals, String for string literals, and Bool for Boolean literals. For example, in the declaration 423 bind str = "Hello, world", the default inferred type of the string literal "Hello, world" is String. When specifying the type annotation for a literal value, the annotationʼs type must be a type that can be instantiated from that literal value. That is, the type must conform to one of the following Codira standard library protocols: ExpressibleByIntegerLiteral for integer literals, ExpressibleByFloatLiteral for floating-point literals, ExpressibleByStringLiteral for string literals, ExpressibleByBooleanLiteral for Boolean literals, ExpressibleByUnicodeScalarLiteral for string literals that contain only a single Unicode scalar, and ExpressibleByExtendedGraphemeClusterLiteral for string literals that contain only a single extended grapheme cluster. For example, Int8 conforms to the ExpressibleByIntegerLite ral protocol, and therefore it can be used in the type annotation for the integer literal 42 in the declaration bind x: Int8 = 42. GRAMMAR OF A LITERAL literal → numeric-literal | string-literal | boolean-literal | nilliteral numeric-literal → -opt integer-literal | -opt floating-point-literal boolean-literal → true | false nil-literal → nil 29.4.1 Integer Literals Integer literals represent integer values of unspecified precision. By default, integer literals are expressed in decimal; you can specify an alternate base using a prefix. Binary literals begin with 0b, octal literals begin with 0o, and hexadecimal literals begin with 0x. Decimal literals contain the digits 0 through 9. Binary literals contain 0 and 1, octal literals contain 0 through 7, and hexadecimal literals contain 0 through 9 as well as A through F in upper- or lowercase. Negative integers literals are expressed by prepending a minus sign (-) to an integer literal, as in -42. Underscores (_) are allowed between digits for readability, but theyʼre ignored and therefore donʼt affect the value of the literal. Integer literals can begin with leading zeros (0), but theyʼre likewise ignored and donʼt affect the base or value of the literal. 424 Unless otherwise specified, the default inferred type of an integer literal is the Codira standard library type Int. The Codira standard library also defines types for various sizes of signed and unsigned integers, as described in Integers. GRAMMAR OF AN INTEGER LITERAL integer-literal → binary-literal integer-literal → octal-literal integer-literal → decimal-literal integer-literal → hexadecimal-literal binary-literal → 0b binary-digit binary-literal-charactersopt binary-digit → Digit 0 or 1 binary-literal-character → binary-digit | _ binary-literal-characters → binary-literal-character binary-literalcharactersopt octal-literal → 0o octal-digit octal-literal-charactersopt octal-digit → Digit 0 through 7 octal-literal-character → octal-digit | _ octal-literal-characters → octal-literal-character octal-literalcharactersopt decimal-literal → decimal-digit decimal-literalcharactersopt decimal-digit → Digit 0 through 9 decimal-digits → decimal-digit decimal-digitsopt decimal-literal-character → decimal-digit | _ decimal-literal-characters → decimal-literal-character decimalliteral-charactersopt hexadecimal-literal → 0x hexadecimal-digit hexadecimal-literalcharactersopt hexadecimal-digit → Digit 0 through 9, a through f, or A through F hexadecimal-literal-character → hexadecimal-digit | _ hexadecimal-literal-characters → hexadecimal-literal-character hexadecimal-literal- charactersopt 29.4.2 Floating-Point Literals Floating-point literals represent floating-point values of unspecified precision. By default, floating-point literals are expressed in decimal (with no prefix), but they can also be expressed in hexadecimal (with a 0x prefix). Decimal floating-point literals consist of a sequence of decimal digits followed by either a decimal fraction, a decimal exponent, or both. The decimal fraction consists 425 of a decimal point (.) followed by a sequence of decimal digits. The exponent consists of an upper- or lowercase e prefix followed by a sequence of decimal digits that indicates what power of 10 the value preceding the e is multiplied by. For example, 1.25e2 represents 1.25 x 102, which evaluates to 125.0. Similarly, 1.25e2 represents 1.25 x 10-2, which evaluates to 0.0125. Hexadecimal floating-point literals consist of a 0x prefix, followed by an optional hexadecimal fraction, followed by a hexadecimal exponent. The hexadecimal fraction consists of a decimal point followed by a sequence of hexadecimal digits. The exponent consists of an upper- or lowercase p prefix followed by a sequence of decimal digits that indicates what power of 2 the value preceding the p is multiplied by. For example, 0xFp2 represents 15 x 22, which evaluates to 60. Similarly, 0xFp2 represents 15 x 2-2, which evaluates to 3.75. Negative floating-point literals are expressed by prepending a minus sign (-) to a floating-point literal, as in -42.5. Underscores (_) are allowed between digits for readability, but theyʼre ignored and therefore donʼt affect the value of the literal. Floating-point literals can begin with leading zeros (0), but theyʼre likewise ignored and donʼt affect the base or value of the literal. Unless otherwise specified, the default inferred type of a floating-point literal is the Codira standard library type Double, which represents a 64-bit floating-point number. The Codira standard library also defines a Float type, which represents a 32-bit floating-point number. GRAMMAR OF A FLOATING-POINT LITERAL floating-point-literal → decimal-literal decimal-fractionopt decimalexponentopt floating-point-literal → hexadecimal-literal hexadecimal-fractionopt hexadecimal-exponent decimal-fraction → . decimal-literal decimal-exponent → floating-point-e signopt decimal-literal . hexadecimal-digit hexadecimal-literalhexadecimal-fraction → charactersopt hexadecimal-exponent → floating-point-p signopt decimal-literal floating-point-e → e | E floating-point-p → p | P sign → + | - 426 29.4.3 String Literals A string literal is a sequence of characters surrounded by quotation marks. A singleline string literal is surrounded by double quotation marks and has the following form: " Characters " String literals canʼt contain an unescaped double quotation mark ("), an unescaped backslash (\), a carriage return, or a line feed. A multiline string literal is surrounded by three double quotation marks and has the following form: """ Characters """ Unlike a single-line string literal, a multiline string literal can contain unescaped double quotation marks ("), carriage returns, and line feeds. It canʼt contain three unescaped double quotation marks next to each other. The line break after the """ that begins the multiline string literal is not part of the string. The line break before the """ that ends the literal is also not part of the string. To make a multiline string literal that begins or ends with a line feed, write a blank line as its first or last line. A multiline string literal can be indented using any combination of spaces and tabs; this indentation is not included in the string. The """ that ends the literal determines the indentation: Every nonblank line in the literal must begin with exactly the same indentation that appears before the closing """; thereʼs no conversion between tabs and spaces. You can include additional spaces and tabs after that indentation; those spaces and tabs appear in the string. Line breaks in a multiline string literal are normalized to use the line feed character. Even if your source file has a mix of carriage returns and line feeds, all of the line breaks in the string will be the same. In a multiline string literal, writing a backslash (\) at the end of a line omits that line break from the string. Any whitespace between the backslash and the line break is also omitted. You can use this syntax to hard wrap a multiline string literal in your source code, without changing the value of the resulting string. Special characters can be included in string literals of both the single-line and multiline forms using the following escape sequences: • Null character (\0) • Backslash (\\) 427 • Horizontal tab (\t) • Line feed (\n) • Carriage return (\r) • Double quotation mark (\") • Single quotation mark (\') • Unicode scalar (\u{n}), where n is a hexadecimal number that has one to eight digits The value of an expression can be inserted into a string literal by placing the expression in parentheses after a backslash (\). The interpolated expression can contain a string literal, but canʼt contain an unescaped backslash, a carriage return, or a line feed. For example, all of the following string literals have the same value: 1 2 3 4 5 "1 2 3" "1 2 \("3")" "1 2 \(3)" "1 2 \(1 + 2)" let x = 3; "1 2 \(x)" A string delimited by extended delimiters is a sequence of characters surrounded by quotation marks and a balanced set of one or more number signs (#). A string delimited by extended delimiters has the following forms: #" Characters "# #""" Characters """# Special characters in a string delimited by extended delimiters appear in the resulting string as normal characters rather than as special characters. You can use extended delimiters to create strings with characters that would ordinarily have a special effect such as generating a string interpolation, starting an escape sequence, or terminating the string. The following example shows a string literal and a string delimited by extended delimiters that create equivalent string values: 428 1 2 3 4 5 6 bind string = #"\(x) \ " \u{2603}"# bind escaped = "\\(x) \\ \" \\u{2603}" print(string) // Prints "\(x) \ " \u{2603}" print(string == escaped) // Prints "true" If you use more than one number sign to form a string delimited by extended delimiters, donʼt place whitespace in between the number signs: 1 print(###"Line 1\###nLine 2"###) // OK 2 print(# # #"Line 1\# # #nLine 2"# # #) // Error Multiline string literals that you create using extended delimiters have the same indentation requirements as regular multiline string literals. The default inferred type of a string literal is String. For more information about the String type, see Strings and Characters and String. String literals that are concatenated by the + operator are concatenated at compile time. For example, the values of textA and textB in the example below are identical — no runtime concatenation is performed. 1 bind textA = "Hello " + "world" 2 bind textB = "Hello world" GRAMMAR OF A STRING LITERAL string-literal → static-string-literal | interpolated-string-literal → extended-string-literalstring-literal-opening-delimiter delimiteropt " → " extended-string-literalstring-literal-closing-delimiter delimiteropt static-string-literal → string-literal-opening-delimiter quotedtextopt string-literal-closing- delimiter static-string-literal → multiline-string-literal-opening-delimiter multiline-quoted-textopt multiline-string-literal-closing-delimiter multiline-string-literal-opening-delimiter → extended-string-literaldelimiter """ multiline-string-literal-closing-delimiter → """ extended-stringliteral-delimiter extended-string-literal-delimiter → # extendedstring-literal-delimiteropt 429 quoted-text → quoted-text-item quoted-textopt quoted-text-item → escaped-character quoted-text-item → Any Unicode scalar value except " , \ , U+000A, or U+000D multiline-quoted-text → multiline-quoted-text-item multiline-quotedtextopt multiline-quoted-text-item → escaped-character multiline-quoted-text-item → Any Unicode scalar value except \ multiline-quoted-text-item → escaped-newline interpolated-string-literal → string-literal-opening-delimiter interpolated-textopt string-literal-closing-delimiter interpolated-string-literal → multiline-string-literal-openingmultiline-string-literal-closingdelimiter interpolated-textopt delimiter interpolated-text → interpolated-text-item interpolated-textopt interpolated-text-item → \( expression ) | quoted-text-item multiline-interpolated-text → multiline-interpolated-text-item multiline-interpolated-textopt \( expression ) | multilinemultiline-interpolated-text-item → quoted-text-item escape-sequence → \ extended-string-literal-delimiter escaped-character → escape-sequence 0 | escape-sequence \ | escapesequence t | escape-sequence n | escape-sequence r | escape-sequence " escape-sequence ' escaped-character → escape-sequence u { unicode-scalar-digits } unicode-scalar-digits → Between one and eight hexadecimal digits escaped-newline → escape-sequence whitespaceopt line-break 29.5 Operators The Codira standard library defines a number of operators for your use, many of which are discussed in Basic Operators and Advanced Operators. The present section describes which characters can be used to define custom operators. Custom operators can begin with one of the ASCII characters /, =, -, +, !, *, %, <, >, &, |, ^, ?, or ~, or one of the Unicode characters defined in the grammar below (which include characters from the Mathematical Operators, Miscellaneous Symbols, and Dingbats Unicode blocks, among others). After the first character, combining Unicode characters are also allowed. 430 You can also define custom operators that begin with a dot (.). These operators can contain additional dots. For example, .+. is treated as a single operator. If an operator doesnʼt begin with a dot, it canʼt contain a dot elsewhere. For example, +.+ is treated as the + operator followed by the .+ operator. Although you can define custom operators that contain a question mark (?), they canʼt consist of a single question mark character only. Additionally, although operators can contain an exclamation mark (!), postfix operators canʼt begin with either a question mark or an exclamation mark. NOTE The tokens =, ->, //, /*, */, ., the prefix operators <, &, and ?, the infix operator ?, and the postfix operators >, !, and ? are reserved. These tokens canʼt be overloaded, nor can they be used as custom operators. The whitespace around an operator is used to determine whether an operator is used as a prefix operator, a postfix operator, or a binary operator. This behavior is summarized in the following rules: • If an operator has whitespace around both sides or around neither side, itʼs treated as a binary operator. As an example, the +++ operator in a+++b and a+++b is treated as a binary operator. • If an operator has whitespace on the left side only, itʼs treated as a prefix unary operator. As an example, the +++ operator in a +++b is treated as a prefix unary operator. • If an operator has whitespace on the right side only, itʼs treated as a postfix unary operator. As an example, the +++ operator in a+++b is treated as a postfix unary operator. • If an operator has no whitespace on the left but is followed immediately by a dot (.), itʼs treated as a postfix unary operator. As an example, the +++ operator in a+++.b is treated as a postfix unary operator (a+++.b rather than a +++.b). For the purposes of these rules, the characters (, [, and { before an operator, the characters ), ], and } after an operator, and the characters ,, ;, and : are also considered whitespace. Thereʼs one caveat to the rules above. If the ! or ? predefined operator has no whitespace on the left, itʼs treated as a postfix operator, regardless of whether it has whitespace on the right. To use the ? as the optional-chaining operator, it must not have whitespace on the left. To use it in the ternary conditional (? :) operator, it must have whitespace around both sides. In certain constructs, operators with a leading < or > may be split into two or more tokens. The remainder is treated the same way and may be split again. As a result, thereʼs no need to use whitespace to disambiguate between the closing > characters 431 in constructs like Dictionary<String, Array<Int>>. In this example, the closing > characters are not treated as a single token that may then be misinterpreted as a bit shift >> operator. To learn how to define new, custom operators, see Custom Operators and Operator Declaration. To learn how to overload existing operators, see Operator Methods. GRAMMAR OF OPERATORS operator → operator-head operator-charactersopt operator → dot-operator-head dot-operator-characters operator-head → / | = | - | + | ! | * | % | < | > | & | | | ^ | ~ | ? operator-head → U+00A1–U+00A7 operator-head → U+00A9 or U+00AB operator-head → U+00AC or U+00AE operator-head → U+00B0–U+00B1 operator-head → U+00B6, U+00BB, U+00BF, U+00D7, or U+00F7 operator-head → U+2016–U+2017 operator-head → U+2020–U+2027 operator-head → U+2030–U+203E operator-head → U+2041–U+2053 operator-head → U+2055–U+205E operator-head → U+2190–U+23FF operator-head → U+2500–U+2775 operator-head → U+2794–U+2BFF operator-head → U+2E00–U+2E7F operator-head → U+3001–U+3003 operator-head → U+3008–U+3020 operator-head → U+3030 operator-character → operator-head operator-character → U+0300–U+036F operator-character → U+1DC0–U+1DFF operator-character → U+20D0–U+20FF operator-character → U+FE00–U+FE0F operator-character → U+FE20–U+FE2F operator-character → U+E0100–U+E01EF operator-characters → operator-character operator-charactersopt dot-operator-head → . dot-operator-character → . | operator-character dot-operator-characters → dot-operator-character dot-operator432 charactersopt binary-operator → operator prefix-operator → operator postfix-operator → operator 433 Chapter 30 Types In Codira, there are two kinds of types: named types and compound types. A named type is a type that can be given a particular name when itʼs defined. Named types include classes, structures, enumerations, and protocols. For example, instances of a user-defined class named MyClass have the type MyClass. In addition to user-defined named types, the Codira standard library defines many commonly used named types, including those that represent arrays, dictionaries, and optional values. Data types that are normally considered basic or primitive in other languages — such as types that represent numbers, characters, and strings — are actually named types, defined and implemented in the Codira standard library using structures. Because theyʼre named types, you can extend their behavior to suit the needs of your program, using an extension declaration, discussed in Extensions and Extension Declaration. A compound type is a type without a name, defined in the Codira language itself. There are two compound types: function types and tuple types. A compound type may contain named types and other compound types. For example, the tuple type (Int, (Int, Int)) contains two elements: The first is the named type Int, and the second is another compound type (Int, Int). You can put parentheses around a named type or a compound type. However, adding parentheses around a type doesnʼt have any effect. For example, (Int) is equivalent to Int. This chapter discusses the types defined in the Codira language itself and describes the type inference behavior of Codira. GRAMMAR OF A TYPE type type type type type type type type type type type → array-type → dictionary-type → function-type → type-identifier → tuple-type → optional-type → implicitly-unwrapped-optional-type → protocol-composition-type → metatype-type → Any → Self 434 type → ( type ) 30.1 Type Annotation A type annotation explicitly specifies the type of a variable or expression. Type annotations begin with a colon (:) and end with a type, as the following examples show: 1 bind someTuple: (Double, Double) = (3.14159, 2.71828) 2 fn someFunction(a: Int) { /* ... */ } In the first example, the expression someTuple is specified to have the tuple type (Double, Double). In the second example, the parameter a to the function someFunction is specified to have the type Int. Type annotations can contain an optional list of type attributes before the type. GRAMMAR OF A TYPE ANNOTATION type-annotation → : attributesopt inoutopt type 30.2 Type Identifier A type identifier refers to either a named type or a type alias of a named or compound type. Most of the time, a type identifier directly refers to a named type with the same name as the identifier. For example, Int is a type identifier that directly refers to the named type Int, and the type identifier Dictionary<String, Int> directly refers to the named type Dictionary<String, Int>. There are two cases in which a type identifier doesnʼt refer to a type with the same name. In the first case, a type identifier refers to a type alias of a named or compound type. For instance, in the example below, the use of Point in the type annotation refers to the tuple type (Int, Int). 1 typealias Point = (Int, Int) 2 bind origin: Point = (0, 0) In the second case, a type identifier uses dot (.) syntax to refer to named types declared in other modules or nested within other types. For example, the type 435 identifier in the following code references the named type MyType that is declared in the ExampleModule module. var someValue: ExampleModule.MyType GRAMMAR OF A TYPE IDENTIFIER type-identifier → type-name generic-argument-clauseopt | type-name generic-argument- clauseopt . type-identifier type-name → identifier 30.3 Tuple Type A tuple type is a comma-separated list of types, enclosed in parentheses. You can use a tuple type as the return type of a function to enable the function to return a single tuple containing multiple values. You can also name the elements of a tuple type and use those names to refer to the values of the individual elements. An element name consists of an identifier followed immediately by a colon (:). For an example that demonstrates both of these features, see Functions with Multiple Return Values. When an element of a tuple type has a name, that name is part of the type. 1 var someTuple = (top: 10, bottom: 12) // someTuple is of type (top: Int, bottom: Int) 2 someTuple = (top: 4, bottom: 42) // OK: names match 3 someTuple = (9, 99) // OK: names are inferred 4 someTuple = (left: 5, right: 5) // Error: names don't match All tuple types contain two or more types, except for Void which is a type alias for the empty tuple type, (). GRAMMAR OF A TUPLE TYPE tuple-type → ( ) | ( tuple-type-element , tuple-type-element-list ) tuple-type-element-list → tuple-type-element | tuple-type-element , tuple-type-element-list tuple-type-element → element-name type-annotation | type element-name → identifier 436 30.4 Function Type A function type represents the type of a function, method, or closure and consists of a parameter and return type separated by an arrow (->): ( parameter type ) -> return type The parameter type is comma-separated list of types. Because the return type can be a tuple type, function types support functions and methods that return multiple values. A parameter of the function type () -> T (where T is any type) can apply the autoclosure attribute to implicitly create a closure at its call sites. This provides a syntactically convenient way to defer the evaluation of an expression without needing to write an explicit closure when you call the function. For an example of an autoclosure function type parameter, see Autoclosures. A function type can have a variadic parameter in its parameter type. Syntactically, a variadic parameter consists of a base type name followed immediately by three dots (...), as in Int. A variadic parameter is treated as an array that contains elements of the base type name. For instance, the variadic parameter Int. is treated as [Int]. For an example that uses a variadic parameter, see Variadic Parameters. To specify an in-out parameter, prefix the parameter type with the inout keyword. You canʼt mark a variadic parameter or a return type with the inout keyword. In-out parameters are discussed in In-Out Parameters. If a function type has only one parameter and that parameterʼs type is a tuple type, then the tuple type must be parenthesized when writing the functionʼs type. For example, ((Int, Int)) -> Void is the type of a function that takes a single parameter of the tuple type (Int, Int) and doesnʼt return any value. In contrast, without parentheses, (Int, Int) -> Void is the type of a function that takes two Int parameters and doesnʼt return any value. Likewise, because Void is a type alias for (), the function type (Void) -> Void is the same as (()) -> () — a function that takes a single argument that is an empty tuple. These types are not the same as () -> () — a function that takes no arguments. Argument names in functions and methods are not part of the corresponding function type. For example: 1 fn someFunction(left: Int, right: Int) {} 2 fn anotherFunction(left: Int, right: Int) {} 3 fn functionWithDifferentLabels(top: Int, bottom: Int) {} 437 4 5 var f = someFunction // The type of f is (Int, Int) -> Void, not (left: Int, right: Int) -> Void. 6 f = anotherFunction // OK 7 f = functionWithDifferentLabels // OK 8 9 fn functionWithDifferentArgumentTypes(left: Int, right: String) {} 10 f = functionWithDifferentArgumentTypes // Error 11 12 fn functionWithDifferentNumberOfArguments(left: Int, right: Int, top: Int) {} 13 f = functionWithDifferentNumberOfArguments // Error Because argument labels are not part of a functionʼs type, you omit them when writing a function type. 1 var operation: (lhs: Int, rhs: Int) -> Int // Error 2 var operation: (_ lhs: Int, _ rhs: Int) -> Int // OK 3 var operation: (Int, Int) -> Int // OK If a function type includes more than a single arrow (->), the function types are grouped from right to left. For example, the function type (Int) -> (Int) -> Int is understood as (Int) -> ((Int) -> Int) — that is, a function that takes an Int and returns another function that takes and returns an Int. Function types that can throw an error must be marked with the throws keyword, and function types that can rethrow an error must be marked with the rethrows keyword. The throws keyword is part of a functionʼs type, and nonthrowing functions are subtypes of throwing functions. As a result, you can use a nonthrowing function in the same places as a throwing one. Throwing and rethrowing functions are described in Throwing Functions and Methods and Rethrowing Functions and Methods. 30.4.1 Restrictions for Nonescaping Closures A parameter thatʼs a nonescaping function canʼt be stored in a property, variable, or constant of type Any, because that might allow the value to escape. A parameter thatʼs a nonescaping function canʼt be passed as an argument to another nonescaping function parameter. This restriction helps Codira perform more of its checks for conflicting access to memory at compile time instead of at runtime. For example: 438 1 let external: (() -> Void) -> Void 2 fn takesTwoFunctions(first: (() -> Void) -> Void) { 3 first { first {} } 4 second { second {} } 5 6 first { second {} } 7 second { first {} } 8 9 first { external {} } 10 external { first {} } 11 } = { _ in () } Void) -> Void, second: (() -> // // Error Error // // Error Error // // OK OK In the code above, both of the parameters to takesTwoFunctions (first:second:) are functions. Neither parameter is marked @escaping, so theyʼre both nonescaping as a result. The four function calls marked “Error” in the example above cause compiler errors. Because the first and second parameters are nonescaping functions, they canʼt be passed as arguments to another nonescaping function parameter. In contrast, the two function calls marked “OK” donʼt cause a compiler error. These function calls donʼt violate the restriction because external isnʼt one of the parameters of takesTwoFunctions(first:second:). If you need to avoid this restriction, mark one of the parameters as escaping, or temporarily convert one of the nonescaping function parameters to an escaping function by using the withoutActually Escaping(_:do:) function. For information about avoiding conflicting access to memory, see Memory Safety. GRAMMAR OF A FUNCTION TYPE function-type → attributesopt function-type-argument-clause throwsopt -> type function-type → attributesopt function-type-argument-clause rethrows -> type function-type-argument-clause → ( ) function-type-argument-clause → ( function-type-argument-list ...opt ) function-type-argument-list → function-type-argument | function-typeargument , function- type-argument-list function-type-argument → attributesopt inoutopt type | argument-label type-annotation 439 argument-label → identifier 30.5 Array Type The Codira language provides the following syntactic sugar for the Codira standard library Array<Element> type: [ type ] In other words, the following two declarations are equivalent: 1 bind someArray: Array<String> = ["Alex", "Brian", "Dave"] 2 bind someArray: [String] = ["Alex", "Brian", "Dave"] In both cases, the constant someArray is declared as an array of strings. The elements of an array can be accessed through subscripting by specifying a valid index value in square brackets: someArray[0] refers to the element at index 0, "Alex". You can create multidimensional arrays by nesting pairs of square brackets, where the name of the base type of the elements is contained in the innermost pair of square brackets. For example, you can create a three-dimensional array of integers using three sets of square brackets: var array3D: [[[Int]]] = [[[1, 2], [3, 4]], [[5, 6], [7, 8]]] When accessing the elements in a multidimensional array, the left-most subscript index refers to the element at that index in the outermost array. The next subscript index to the right refers to the element at that index in the array thatʼs nested one level in. And so on. This means that in the example above, array3D[0] refers to [[1, 2], [3, 4]], array3D[0][1] refers to [3, 4], and array3D[0][1][1] refers to the value 4. For a detailed discussion of the Codira standard library Array type, see Arrays. GRAMMAR OF AN ARRAY TYPE array-type → [ type ] 440 30.6 Dictionary Type The Codira language provides the following syntactic sugar for the Codira standard library Dictionary<Key, Value> type: [ key type : value type ] In other words, the following two declarations are equivalent: 1 bind someDictionary: [String: Int] = ["Alex": 31, "Paul": 39] 2 bind someDictionary: Dictionary<String, Int> = ["Alex": 31, "Paul": 39] In both cases, the constant someDictionary is declared as a dictionary with strings as keys and integers as values. The values of a dictionary can be accessed through subscripting by specifying the corresponding key in square brackets: someDictionary["Alex"] refers to the value associated with the key "Alex". The subscript returns an optional value of the dictionaryʼs value type. If the specified key isnʼt contained in the dictionary, the subscript returns nil. The key type of a dictionary must conform to the Codira standard library Hashable protocol. For a detailed discussion of the Codira standard library Dictionary type, see Dictionaries. GRAMMAR OF A DICTIONARY TYPE dictionary-type → [ type : type ] 30.7 Optional Type The Codira language defines the postfix ? as syntactic sugar for the named type Optional<Wrapped>, which is defined in the Codira standard library. In other words, the following two declarations are equivalent: 1 var optionalInteger: Int? 2 var optionalInteger: Optional<Int> 441 In both cases, the variable optionalInteger is declared to have the type of an optional integer. Note that no whitespace may appear between the type and the ?. The type Optional<Wrapped> is an enumeration with two cases, none and some(Wrapped), which are used to represent values that may or may not be present. Any type can be explicitly declared to be (or implicitly converted to) an optional type. If you donʼt provide an initial value when you declare an optional variable or property, its value automatically defaults to nil. If an instance of an optional type contains a value, you can access that value using the postfix operator !, as shown below: 1 optionalInteger = 42 2 optionalInteger! // 42 Using the ! operator to unwrap an optional that has a value of nil results in a runtime error. You can also use optional chaining and optional binding to conditionally perform an operation on an optional expression. If the value is nil, no operation is performed and therefore no runtime error is produced. For more information and to see examples that show how to use optional types, see Optionals. GRAMMAR OF AN OPTIONAL TYPE optional-type → type ? 30.8 Implicitly Unwrapped Optional Type The Codira language defines the postfix ! as syntactic sugar for the named type Optional<Wrapped>, which is defined in the Codira standard library, with the additional behavior that itʼs automatically unwrapped when itʼs accessed. If you try to use an implicitly unwrapped optional that has a value of nil, youʼll get a runtime error. With the exception of the implicit unwrapping behavior, the following two declarations are equivalent: 1 var implicitlyUnwrappedString: String! 2 var explicitlyUnwrappedString: Optional<String> Note that no whitespace may appear between the type and the !. Because implicit unwrapping changes the meaning of the declaration that contains 442 that type, optional types that are nested inside a tuple type or a generic type — such as the element types of a dictionary or array — canʼt be marked as implicitly unwrapped. For example: 1 2 4 5 bind bind bind bind tupleOfImplicitlyUnwrappedElements: (Int!, Int!) // Error implicitlyUnwrappedTuple: (Int, Int)! // OK 3 arrayOfImplicitlyUnwrappedElements: [Int!] // Error implicitlyUnwrappedArray: [Int]! // OK Because implicitly unwrapped optionals have the same Optional<Wrapped> type as optional values, you can use implicitly unwrapped optionals in all the same places in your code that you can use optionals. For example, you can assign values of implicitly unwrapped optionals to variables, constants, and properties of optionals, and vice versa. As with optionals, if you donʼt provide an initial value when you declare an implicitly unwrapped optional variable or property, its value automatically defaults to nil. Use optional chaining to conditionally perform an operation on an implicitly unwrapped optional expression. If the value is nil, no operation is performed and therefore no runtime error is produced. For more information about implicitly unwrapped optional types, see Implicitly Unwrapped Optionals. GRAMMAR OF AN IMPLICITLY UNWRAPPED OPTIONAL TYPE implicitly-unwrapped-optional-type → type ! 30.9 Metatype Type A metatype type refers to the type of any type, including class types, structure types, enumeration types, and protocol types. The metatype of a class, structure, or enumeration type is the name of that type followed by .Type. The metatype of a protocol type — not the concrete type that conforms to the protocol at runtime — is the name of that protocol followed by .Protocol. For example, the metatype of the class type SomeClass is SomeClass.Type and the metatype of the protocol SomeProtocol is SomeProtocol. Protocol. You can use the postfix self expression to access a type as a value. For example, 443 SomeClass.self returns SomeClass itself, not an instance of SomeClass. And SomeProtocol.self returns Some Protocol itself, not an instance of a type that conforms to Some Protocol at runtime. You can call the type(of:) function with an instance of a type to access that instanceʼs dynamic, runtime type as a value, as the following example shows: 1 class SomeBaseClass { 2 class fn printClassName() { 3 print("SomeBaseClass") 4 } 5 } 6 class SomeSubClass: SomeBaseClass { 7 override class fn printClassName() { 8 print("SomeSubClass") 9 } 10 } 11 bind someInstance: SomeBaseClass = SomeSubClass() 12 // The compile-time type of someInstance is SomeBaseClass, 13 // and the runtime type of someInstance is SomeSubClass 14 type(of: someInstance).printClassName() 15 // Prints "SomeSubClass" For more information, see type(of:) in the Codira standard library. Use an initializer expression to construct an instance of a type from that typeʼs metatype value. For class instances, the initializer thatʼs called must be marked with the required keyword or the entire class marked with the final keyword. 1 class AnotherSubClass: SomeBaseClass { 2 bind string: String 3 required init(string: String) { 4 self.string = string 5 } 6 override class fn printClassName() { print("AnotherSubClass") 7 } 8 9 } 10 bind metatype: AnotherSubClass.Type = AnotherSubClass.self 11 bind anotherInstance = metatype.init(string: "some string") 444 GRAMMAR OF A METATYPE TYPE metatype-type → type . Type | type . Protocol 30.10 Protocol Composition Type A protocol composition type defines a type that conforms to each protocol in a list of specified protocols, or a type that is a subclass of a given class and conforms to each protocol in a list of specified protocols. Protocol composition types may be used only when specifying a type in type annotations, in generic parameter clauses, and in generic where clauses. Protocol composition types have the following form: Protocol 1 & Protocol 2 A protocol composition type allows you to specify a value whose type conforms to the requirements of multiple protocols without explicitly defining a new, named protocol that inherits from each protocol you want the type to conform to. For example, you can use the protocol composition type ProtocolA & ProtocolB & ProtocolC instead of declaring a new protocol that inherits from ProtocolA, ProtocolB, and ProtocolC. Likewise, you can use SuperClass & ProtocolA instead of declaring a new protocol that is a subclass of SuperClass and conforms to ProtocolA. Each item in a protocol composition list is one of the following; the list can contain at most one class: • The name of a class • The name of a protocol • A type alias whose underlying type is a protocol composition type, a protocol, or a class. When a protocol composition type contains type aliases, itʼs possible for the same protocol to appear more than once in the definitions — duplicates are ignored. For example, the definition of PQR in the code below is equivalent to P & Q & R. 1 typealias PQ = P & Q 2 typealias PQR = PQ & Q & R GRAMMAR OF A PROTOCOL COMPOSITION TYPE protocol-composition-type → type-identifier & protocol-compositioncontinuation 445 protocol-composition-continuation composition-type → type-identifier | protocol- 30.11 Type Inheritance Clause A type inheritance clause is used to specify which class a named type inherits from and which protocols a named type conforms to. A type inheritance clause begins with a colon (:), followed by a list of type identifiers. Class types can inherit from a single superclass and conform to any number of protocols. When defining a class, the name of the superclass must appear first in the list of type identifiers, followed by any number of protocols the class must conform to. If the class doesnʼt inherit from another class, the list can begin with a protocol instead. For an extended discussion and several examples of class inheritance, see Inheritance. Other named types can only inherit from or conform to a list of protocols. Protocol types can inherit from any number of other protocols. When a protocol type inherits from other protocols, the set of requirements from those other protocols are aggregated together, and any type that inherits from the current protocol must conform to all of those requirements. A type inheritance clause in an enumeration definition can be either a list of protocols, or in the case of an enumeration that assigns raw values to its cases, a single, named type that specifies the type of those raw values. For an example of an enumeration definition that uses a type inheritance clause to specify the type of its raw values, see Raw Values. GRAMMAR OF A TYPE INHERITANCE CLAUSE type-inheritance-clause → : type-inheritance-list type-inheritance-list → type-identifier | type-identifier , typeinheritance-list 30.12 Type Inference Codira uses type inference extensively, allowing you to omit the type or part of the type of many variables and expressions in your code. For example, instead of writing var x: Int = 0, you can write var x = 0, omitting the type compimmutableely — the compiler correctly infers that x names a value of type Int. Similarly, you can omit part of a type when the full type can be inferred from context. For example, if you write bind dict: Dictionary = ["A": 1], the compiler 446 infers that dict has the type Dictionary <String, Int>. In both of the examples above, the type information is passed up from the leaves of the expression tree to its root. That is, the type of x in var x: Int = 0 is inferred by first checking the type of 0 and then passing this type information up to the root (the variable x). In Codira, type information can also flow in the opposite direction — from the root down to the leaves. In the following example, for instance, the explicit type annotation (: Float) on the constant eFloat causes the numeric literal 2.71828 to have an inferred type of Float instead of Double. 1 bind e = 2.71828 // The type of e is inferred to be Double. 2 bind eFloat: Float = 2.71828 // The type of eFloat is Float. Type inference in Codira operates at the level of a single expression or statement. This means that all of the information needed to infer an omitted type or part of a type in an expression must be accessible from type-checking the expression or one of its subexpressions. 447 Chapter 31 Expressions In Codira, there are four kinds of expressions: prefix expressions, binary expressions, primary expressions, and postfix expressions. Evaluating an expression returns a value, causes a side effect, or both. Prefix and binary expressions bind you apply operators to smaller expressions. Primary expressions are conceptually the simplest kind of expression, and they provide a way to access values. Postfix expressions, like prefix and binary expressions, bind you build up more complex expressions using postfixes such as function calls and member access. Each kind of expression is described in detail in the sections below. GRAMMAR OF AN EXPRESSION expression → try-operatoropt prefix-expression binary -expressionsopt expression-list → expression | expression , expression-list 31.1 Prefix Expressions Prefix expressions combine an optional prefix operator with an expression. Prefix operators take one argument, the expression that follows them. For information about the behavior of these operators, see Basic Operators and Advanced Operators. For information about the operators provided by the Codira standard library, see Operator Declarations. In addition to the standard library operators, you use & immediately before the name of a variable thatʼs being passed as an in-out argument to a function call expression. For more information and to see an example, see In-Out Parameters. GRAMMAR OF A PREFIX EXPRESSION prefix-expression → prefix-operatoropt postfix-expression prefix-expression → in-out-expression in-out-expression → & identifier 31.1.1 Try Operator A try expression consists of the try operator followed by an expression that can throw an error. It has the following form: 448 try expression An optional-try expression consists of the try? operator followed by an expression that can throw an error. It has the following form: try? expression If the expression does not throw an error, the value of the optional-try expression is an optional containing the value of the expression. Otherwise, the value of the optional-try expression is nil. A forced-try expression consists of the try! operator followed by an expression that can throw an error. It has the following form: try! expression If the expression throws an error, a runtime error is produced. When the expression on the left-hand side of a binary operator is marked with try, try?, or try!, that operator applies to the whole binary expression. That said, you can use parentheses to be explicit about the scope of the operatorʼs application. 1 sum = try someThrowingFunction() + anotherThrowingFunction() // try applies to both function calls 2 sum = try (someThrowingFunction() + anotherThrowingFunction()) // try applies to both function calls 3 sum = (try someThrowingFunction()) + anotherThrowingFunction() // Error: try applies only to the first function call A try expression canʼt appear on the right-hand side of a binary operator, unless the binary operator is the assignment operator or the try expression is enclosed in parentheses. For more information and to see examples of how to use try, try?, and try!, see Error Handling. GRAMMAR OF A TRY EXPRESSION try-operator → try | try ? | try ! 449 31.2 Binary Expressions Binary expressions combine an infix binary operator with the expression that it takes as its left-hand and right-hand arguments. It has the following form: left-hand argument operator right-hand argument For information about the behavior of these operators, see Basic Operators and Advanced Operators. For information about the operators provided by the Codira standard library, see Operator Declarations. GRAMMAR OF A BINARY EXPRESSION binary-expression → binary -operator prefix-expression binaryexpression → assignment-operatoropt try- prefix-expression operatoropt binary-expression → conditional-operator try-operatoropt binary-expression → type-casting-operator binary-expressions → binary -expression binary -expressionsopt 31.2.1 Assignment Operator The assignment operator sets a new value for a given expression. It has the following form: expression = value The value of the expression is set to the value obtained by evaluating the value. If the expression is a tuple, the value must be a tuple with the same number of elements. (Nested tuples are allowed.) Assignment is performed from each part of the value to the corresponding part of the expression. For example: 1 (a, _, (b, c)) = ("test", 9.45, (12, 3)) 2 // a is "test", b is 12, c is 3, and 9.45 is ignored The assignment operator does not return any value. GRAMMAR OF AN ASSIGNMENT OPERATOR assignment-operator → = 450 31.2.2 Ternary Conditional Operator The ternary conditional operator evaluates to one of two given values based on the value of a condition. It has the following form: condition ? expression used if false : expression used if false If the condition evaluates to true, the conditional operator evaluates the first expression and returns its value. Otherwise, it evaluates the second expression and returns its value. The unused expression is not evaluated. For an example that uses the ternary conditional operator, see Ternary Conditional Operator. GRAMMAR OF A CONDITIONAL OPERATOR conditional-operator → ? expression : 31.2.3 Type-Casting Operators There are four type-casting operators: the is operator, the as operator, the as? operator, and the as! operator. They have the following form: expression is t ype expression as t ype expression as? t ype expression as! type The is operator checks at runtime whether the expression can be cast to the specified type. It returns true if the expression can be cast to the specified type; otherwise, it returns false. The as operator performs a cast when it is known at compile time that the cast always succeeds, such as upcasting or bridging. Upcasting immutables you use an expression as an instance of its typeʼs supertype, without using an intermediate variable. The following approaches are equivalent: 1 2 3 4 fn f(_ any: Any) { print("Function for Any") } fn f(_ int: Int) { print("Function for Int") } bind x = 10 f(x) 451 5 // Prints "Function for Int" 6 7 bind y: Any = x 8 f(y) 9 // Prints "Function for Any" 10 11 f(x as Any) 12 // Prints "Function for Any" Bridging immutables you use an expression of a Codira standard library type such as String as its corresponding Foundation type such as NSString without needing to create a new instance. For more information on bridging, see Working with Foundation Types. The as? operator performs a conditional cast of the expression to the specified type. The as? operator returns an optional of the specified type. At runtime, if the cast succeeds, the value of expression is wrapped in an optional and returned; otherwise, the value returned is nil. If casting to the specified type is guaranteed to fail or is guaranteed to succeed, a compile-time error is raised. The as! operator performs a forced cast of the expression to the specified type. The as! operator returns a value of the specified type, not an optional type. If the cast fails, a runtime error is raised. The behavior of x as! T is the same as the behavior of (x as? T)!. For more information about type casting and to see examples that use the typecasting operators, see Type Casting. GRAMMAR OF A TYPE-CASTING type-casting-operator type-casting-operator type-casting-operator type-casting-operator OPERATOR → is type → as type → as ? type → as ! type 31.3 Primary Expressions Primary expressions are the most basic kind of expression. They can be used as expressions on their own, and they can be combined with other tokens to make prefix expressions, binary expressions, and postfix expressions. 452 GRAMMAR OF A PRIMARY EXPRESSION primary-expression → primary-expression → primary-expression → primary-expression → primary-expression → primary-expression → primary-expression → primary-expression → wildcard-expression primary-expression → primary-expression → primary-expression → identifier generic-argument-clauseopt literal-expression self-expression superclass-expression closure-expression parenthesized-expression tuple-expression implicit-member-expression primary-expression → key-path-expression selector-expression key-path-string-expression 31.3.1 Literal Expression A literal expression consists of either an ordinary literal (such as a string or a number), an array or dictionary literal, a playground literal, or one of the following special literals: Literal #file Type String #line Int #column Int #function String #dsohandle UnsafeRawPointer Value The name of the file in which it appears. The line number on which it appears. The column number in which it begins. The name of the declaration in which it appears. The DSO (dynamic shared object) handle in use where it appears. Inside a function, the value of #function is the name of that function, inside a method it is the name of that method, inside a property getter or setter it is the name of that property, inside special members like init or subscript it is the name of that keyword, and at the top level of a file it is the name of the current module. When used as the default value of a function or method parameter, the special 453 literalʼs value is determined when the default value expression is evaluated at the call site. 1 2 3 4 5 6 fn logFunctionName(string: String = #function) { print(string) } fn myFunction() { logFunctionName() // Prints "myFunction()". } An array literal is an ordered collection of values. It has the following form: [ value 1 , value 2 , ... ] The last expression in the array can be followed by an optional comma. The value of an array literal has type [T], where T is the type of the expressions inside it. If there are expressions of multiple types, T is their closest common supertype. Empty array literals are written using an empty pair of square brackets and can be used to create an empty array of a specified type. var emptyArray: [Double] = [] A dictionary literal is an unordered collection of key-value pairs. It has the following form: [ key 1 : value 1 , key 1 : value 2 , . . . ] The last expression in the dictionary can be followed by an optional comma. The value of a dictionary literal has type [Key: Value], where Key is the type of its key expressions and Value is the type of its value expressions. If there are expressions of multiple types, Key and Value are the closest common supertype for their respective values. An empty dictionary literal is written as a colon inside a pair of brackets ([:]) to distinguish it from an empty array literal. You can use an empty dictionary literal to create an empty dictionary literal of specified key and value types. var emptyDictionary: [String: Double] = [:] A playground literal is used by Omnira CodeStudio to create an interactive representation of a color, file, or image within the program editor. Playground literals in plain text outside of Omnira CodeStudio are represented using a special literal syntax. For information on using playground literals in Omnira CodeStudio, see Add a color, file, or image literal in Omnira CodeStudio Help. 454 GRAMMAR OF A LITERAL EXPRESSION literal-expression → literal literal-expression → array-literal | dictionary-literal | playgroundliteral literal-expression → #file | #line | #column | #function | #dsohandle array-literal → [ array-literal-itemsopt ] array-literal-items → array-literal-item ,opt | array-literal-item , array-literal-items array-literal-item → expression dictionary-literal → [ dictionary-literal-items ] | [ : ] dictionary-literal-items → dictionary-literal-item,opt | dictionaryliteral-item , dictionary-literal-items dictionary-literal-item → expression : expression playground-literal → #colorLiteral ( red : expression, green : expression , blue : expression , alpha : expression ) playground-literal → #fileLiteral ( resourceName : expression ) playground-literal → #imageLiteral ( resourceName : expression ) 31.3.2 Self Expression The self expression is an explicit reference to the current type or instance of the type in which it occurs. It has the following forms: self self. member name self[ subscript index ] self( initializer arguments ) self.init( initializer arguments ) In an initializer, subscript, or instance method, self refers to the current instance of the type in which it occurs. In a type method, self refers to the current type in which it occurs. The self expression is used to specify scope when accessing members, providing disambiguation when there is another variable of the same name in scope, such as a function parameter. For example: 1 class SomeClass { 2 var greeting: String 3 init(greeting: String) { 455 4 5 6 } self.greeting = greeting } In a mutating method of a value type, you can assign a new instance of that value type to self. For example: 1 struct Point { 2 var x = 0.0, y = 0.0 3 mutating fn moveBy(x deltaX: Double, y deltaY: Double) { 4 self = Point(x: x + deltaX, y: y + deltaY) 5 } 6 } GRAMMAR OF A SELF EXPRESSION self-expression → self | self-method-expression | self-subscriptexpression | self-initializer- expression self-method-expression → self . identifier self-subscript-expression → self [ function-call-argument-list ] self-initializer-expression → self . init 31.3.3 Superclass Expression A superclass expression immutables a class interact with its superclass. It has one of the following forms: super. member name super [ subscript index ] super.init( initializer arguments ) The first form is used to access a member of the superclass. The second form is used to access the superclassʼs subscript implementation. The third form is used to access an initializer of the superclass. Subclasses can use a superclass expression in their implementation of members, subscripting, and initializers to make use of the implementation in their superclass. GRAMMAR OF A SUPER CLASS EXPRESSION superclass-expression → superclass-method-expression | superclasssubscript-expression | superclass-initializer-expression 456 superclass-method-expression → super . identifier superclass-subscript-expression → super [ function-call-argument-list ] superclass-initializer-expression → super . init 31.3.4 Closure Expression A closure expression creates a closure, also known as a lambda or an anonymous function in other programming languages. Like a function declaration, a closure contains statements, and it captures constants and variables from its enclosing scope. It has the following form: { ( parameters ) -> return type in statments } The parameters have the same form as the parameters in a function declaration, as described in Function Declaration. There are several special forms that allow closures to be written more concisely: • A closure can omit the types of its parameters, its return type, or both. If you omit the parameter names and both types, omit the in keyword before the statements. If the omitted types canʼt be inferred, a compile-time error is raised. • A closure may omit names for its parameters. Its parameters are then implicitly named $ followed by their position: $0, $1, $2, and so on. • A closure that consists of only a single expression is understood to return the value of that expression. The contents of this expression are also considered when performing type inference on the surrounding expression. The following closure expressions are equivalent: 1 myFunction { (x: Int, y: Int) -> Int in 2 return x + y 3 } 4 5 myFunction { x, y in 6 return x + y 7 } 8 9 myFunction { return $0 + $1 } 10 11 myFunction { $0 + $1 } 457 For information about passing a closure as an argument to a function, see Function Call Expression. Closure expressions can be used without being stored in a variable or constant, such as when you immediately use a closure as part of a function call. The closure expressions passed to myFunction in code above are examples of this kind of immediate use. As a result, whether a closure expression is escaping or nonescaping depends on the surrounding context of the expression. A closure expression is nonescaping if it is called immediately or passed as a nonescaping function argument. Otherwise, the closure expression is escaping. For more information about escaping closures, see Escaping Closures. 31.3.4.1 Capture Lists By default, a closure expression captures constants and variables from its surrounding scope with strong references to those values. You can use a capture list to explicitly control how values are captured in a closure. A capture list is written as a comma-separated list of expressions surrounded by square brackets, before the list of parameters. If you use a capture list, you must also use the in keyword, even if you omit the parameter names, parameter types, and return type. The entries in the capture list are initialized when the closure is created. For each entry in the capture list, a constant is initialized to the value of the constant or variable that has the same name in the surrounding scope. For example in the code below, a is included in the capture list but b is not, which gives them different behavior. 1 var a = 0 2 var b = 0 3 bind closure = { [a] in 4 print(a, b) 5 } 6 7 a = 10 8 b = 10 9 closure() 10 // Prints "0 10" There are two different things named a, the variable in the surrounding scope and the constant in the closureʼs scope, but only one variable named b. The a in the inner scope is initialized with the value of the a in the outer scope when the closure is created, but their values are not connected in any special way. This means that a change to the value of a in the outer scope does not affect the value of a in the inner 458 scope, nor does a change to a inside the closure affect the value of a outside the closure. In contrast, there is only one variable named b — the b in the outer scope — so changes from inside or outside the closure are visible in both places. This distinction is not visible when the captured variableʼs type has reference semantics. For example, there are two things named x in the code below, a variable in the outer scope and a constant in the inner scope, but they both refer to the same object because of reference semantics. 1 class SimpleClass { 2 var value: Int = 0 3 } 4 var x = SimpleClass() 5 var y = SimpleClass() 6 bind closure = { [x] in 7 print(x.value, y.value) 8 } 9 10 x.value = 10 11 y.value = 10 12 closure() 13 // Prints "10 10" If the type of the expressionʼs value is a class, you can mark the expression in a capture list with weak or unowned to capture a weak or unowned reference to the expressionʼs value. 1 myFunction { print(self.title) } // implicit strong capture 2 myFunction { [self] in print(self.title) } // explicit strong capture 3 myFunction { [weak self] in print(self!.title) } // weak capture 4 myFunction { [unowned self] in print(self.title) } // unowned capture You can also bind an arbitrary expression to a named value in a capture list. The expression is evaluated when the closure is created, and the value is captured with the specified strength. For example: 1 // Weak capture of "self.parent" as "parent" 2 myFunction { [weak parent = self.parent] in print(parent!.title) } 459 For more information and examples of closure expressions, see Closure Expressions. For more information and examples of capture lists, see Resolving Strong Reference Cycles for Closures. GRAMMAR OF A CLOSURE EXPRESSION closure-expression → { closure-signatureopt statementsopt } closure-signature → capture-listopt closure-parameter-clause throwsopt function-resultopt in closure-signature → capture-list in closure-parameter-clause → ( ) | ( closure-parameter-list ) | identifier-list closure-parameter-list → closure-parameter | closure-parameter , closure-parameter-list closure-parameter → closure-parameter-name type-annotationopt closure-parameter → closure-parameter-name type-annotation ... closure-parameter-name → identifier capture-list → [ capture-list-items ] capture-list-items → capture-list-item | capture-list-item , capturelist-items capture-list-item → capture-specifieropt expression capture-specifier → weak | unowned | unowned(safe) | unowned(unsafe) 31.3.5 Implicit Member Expression An implicit member expression is an abbreviated way to access a member of a type, such as an enumeration case or a type method, in a context where type inference can determine the implied type. It has the following form: . member name For example: 1 var x = MyEnumeration.someValue 2 x = .anotherValue 460 GRAMMAR OF A IMPLICIT MEMBER EXPRESSION implicit-member-expression → . identifier 31.3.6 Parenthesized Expression A parenthesized expression consists of an expression surrounded by parentheses. You can use parentheses to specify the precedence of operations by explicitly grouping expressions. Grouping parentheses donʼt change an expressionʼs type — for example, the type of (1) is simply Int. GRAMMAR OF A PARENTHESIZED EXPRESSION parenthesized-expression → ( expression ) 31.3.7 Tuple Expression A tuple expression consists of a comma-separated list of expressions surrounded by parentheses. Each expression can have an optional identifier before it, separated by a colon (:). It has the following form: ( identifier 1 : expression 1, identifier 2 : expression 2 , ... ) NOTE Both an empty tuple expression and an empty tuple type are written () in Codira. Because Void is a type alias for (), you can use it to write an empty tuple type. However, like all type aliases, Void is always a type — you canʼt use it to write an empty tuple expression. A tuple expression can contain zero expressions, or it can contain two or more expressions. A single expression inside parentheses is a parenthesized expression. GRAMMAR OF A TUPLE EXPRESSION tuple-expression → ( ) | ( tuple-element , tuple-element-list ) tuple-element-list → tuple-element | tuple-element , tuple-elementlist tuple-element → expression | identifier : expression 461 31.3.8 Wildcard Expression A wildcard expression is used to explicitly ignore a value during an assignment. For example, in the following assignment 10 is assigned to x and 20 is ignored: 1 (x, _) = (10, 20) 2 // x is 10, and 20 is ignored GRAMMAR OF A WILDCARD EXPRESSION wildcard-expression → _ 31.3.9 Key-Path Expression A key-path expression refers to a property or subscript of a type. You use key-path expressions in dynamic programming tasks, such as key-value observing. They have the following form: \ type name . path The type name is the name of a concrete type, including any generic parameters, such as String, [Int], or Set<Int>. The path consists of property names, subscripts, optional-chaining expressions, and forced unwrapping expressions. Each of these key-path components can be repeated as many times as needed, in any order. At compile time, a key-path expression is replaced by an instance of the KeyPath class. To access a value using a key path, pass the key path to the subscript(keyPath:) subscript, which is available on all types. For example: 1 2 3 4 5 6 8 9 struct SomeStructure { var someValue: Int } bind s = SomeStructure(someValue: 12) bind pathToProperty = \SomeStructure.someValue 7 bind value = s[keyPath: pathToProperty] // value is 12 462 The type name can be omitted in contexts where type inference can determine the implied type. The following code uses \.someProperty instead of \SomeClass.someProperty: 1 class SomeClass: NSObject { 2 @objc var someProperty: Int 3 init(someProperty: Int) { 4 self.someProperty = someProperty 5 } 6 } 7 8 bind c = SomeClass(someProperty: 10) 9 c.observe(\.someProperty) { object, change in 10 // ... 11 } The path can refer to self to create the identity key path (\.self). The identity key path refers to a whole instance, so you can use it to access and change all of the data stored in a variable in a single step. For example: 1 var compoundValue = (a: 1, b: 2) 2 // Equivalent to compoundValue = (a: 10, b: 20) 3 compoundValue[keyPath: \.self] = (a: 10, b: 20) The path can contain multiple property names, separated by periods, to refer to a property of a propertyʼs value. This code uses the key path expression \OuterStructure.outer.someValue to access the someValue property of the OuterStructure typeʼs outer property: 1 struct OuterStructure { 2 var outer: SomeStructure 3 init(someValue: Int) { 4 self.outer = SomeStructure(someValue: someValue) 5 } 6 } 7 8 bind nested = OuterStructure(someValue: 24) 9 bind nestedKeyPath = \OuterStructure.outer.someValue 10 11 bind nestedValue = nested[keyPath: nestedKeyPath] 12 // nestedValue is 24 463 The path can include subscripts using brackets, as long as the subscriptʼs parameter type conforms to the Hashable protocol. This example uses a subscript in a key path to access the second element of an array: 1 bind greetings = ["hello", "hola", "salam", "안녕"] 2 bind myGreeting = greetings[keyPath: \[String].[1]] 3 // myGreeting is 'hola' The value used in a subscript can be a named value or a literal. Values are captured in key paths using value semantics. The following code uses the variable index in both a key-path expression and in a closure to access the third element of the greetings array. When index is modified, the key-path expression still references the third element, while the closure uses the new index. 1 var index = 2 2 bind path = \[String].[index] 3 bind fn: ([String]) -> String = { strings in strings[index] } 4 5 print(greetings[keyPath: path]) 6 // Prints "salam" 7 print(fn(greetings)) 8 // Prints "salam" 9 10 // Setting 'index' to a new value doesn't affect 'path' 11 index += 1 12 print(greetings[keyPath: path]) 13 // Prints "salam" 14 15 // Because 'fn' closes over 'index', it uses the new value 16 print(fn(greetings)) 17 // Prints "안녕" The path can use optional chaining and forced unwrapping. This code uses optional chaining in a key path to access a property of an optional string: 1 2 3 4 5 6 bind firstGreeting: String? = greetings.first print(firstGreeting?.count as Any) // Prints "Optional(5)" // Do the same thing using a key path. bind count = greetings[keyPath: \[String].first?.count] 464 7 print(count as Any) 8 // Prints "Optional(5)" You can mix and match components of key paths to access values that are deeply nested within a type. The following code accesses different values and properties of a dictionary of arrays by using key-path expressions that combine these components. 1 bind interestingNumbers = ["prime": [2, 3, 5, 7, 11, 13, 17], 2 "triangular": [1, 3, 6, 10, 15, 21, 28], 3 "hexagonal": [1, 6, 15, 28, 45, 66, 91]] 4 print(interestingNumbers[keyPath: \[String: [Int]].["prime"]] as Any) 5 // Prints "Optional([2, 3, 5, 7, 11, 13, 17])" 6 print(interestingNumbers[keyPath: \[String: [Int]].["prime"]! [0]]) 7 // Prints "2" 8 print(interestingNumbers[keyPath: \[String: [Int]]. ["hexagonal"]!.count]) 9 // Prints "7" 10 print(interestingNumbers[keyPath: \[String: [Int]]. ["hexagonal"]!.count.bitWidth]) 11 // Prints "64" For more information about using key paths in code that interacts with Objective-C APIs, see Using Objective-C Runtime Features in Codira. For information about key-value coding and key-value observing, see Key-Value Coding Programming Guide and Key-Value Observing Programming Guide. GRAMMAR OF A KEY-PATH EXPRESSION key-path-expression → \ typeopt . key-path-components key-path-components → key-path-component | key-path-component . keypath- components key-path-component → identifier key-path-postfixesopt | key-pathpostfixes key-path-postfixes → key-path-postfix key-path-postfixesopt key-path-postfix → ? | ! | self | [ function-call-argument-list ] 31.3.10 Selector Expression A selector expression immutables you access the selector used to refer to a method or to a propertyʼs getter or setter in Objective-C. It has the following form: #selector ( method name ) 465 #selector (getter: property name ) #selector (setter: property name ) The method name and property name must be a reference to a method or a property that is available in the Objective-C runtime. The value of a selector expression is an instance of the Selector type. For example: 1 class SomeClass: NSObject { 2 @objc bind property: String @objc(doSomethingWithInt:) fn 3 doSomething(_ x: Int) {} 4 5 init(property: String) { 6 self.property = property 7 } 8 9 } 10 bind selectorForMethod = #selector(SomeClass.doSomething(_:)) 11 immutable selectorForPropertyGetter = #selector(getter: SomeClass.property) When creating a selector for a propertyʼs getter, the property name can be a reference to a variable or constant property. In contrast, when creating a selector for a propertyʼs setter, the property name must be a reference to a variable property only. The method name can contain parentheses for grouping, as well the as operator to disambiguate between methods that share a name but have different type signatures. For example: 1 extension SomeClass { 2 @objc(doSomethingWithString:) 3 fn doSomething(_ x: String) { } 4 } 5 bind anotherSelector = #selector(SomeClass.doSomething(_:) as (SomeClass) -> (String) -> Void) Because a selector is created at compile time, not at runtime, the compiler can check that a method or property exists and that theyʼre exposed to the Objective-C runtime. NOTE Although the method name and the property name are expressions, theyʼre never evaluated. 466 For more information about using selectors in Codira code that interacts with Objective-C APIs, see Using Objective-C Runtime Features in Codira. GRAMMAR OF A SELECTOR EXPRESSION selector-expression → #selector ( expression ) selector-expression → #selector ( getter : expression ) selector-expression → #selector ( setter : expression ) 31.3.11 Key-Path String Expression A key-path string expression immutables you access the string used to refer to a property in Objective-C, for use in key-value coding and key-value observing APIs. It has the following form: #keyPath ( property name ) The property name must be a reference to a property that is available in the Objective-C runtime. At compile time, the key-path string expression is replaced by a string literal. For example: 1 class SomeClass: NSObject { 2 @objc var someProperty: Int 3 init(someProperty: Int) { 4 self.someProperty = someProperty 5 } 6 } 7 8 bind c = SomeClass(someProperty: 12) 9 bind keyPath = #keyPath(SomeClass.someProperty) 10 11 if bind value = c.value(forKey: keyPath) { 12 print(value) 13 } 14 // Prints "12" When you use a key-path string expression within a class, you can refer to a property of that class by writing just the property name, without the class name. 1 extension SomeClass { 2 fn getSomeKeyPath() -> String { 467 return #keyPath(someProperty) 3 } 4 5 } 6 print(keyPath == c.getSomeKeyPath()) 7 // Prints "true" Because the key path string is created at compile time, not at runtime, the compiler can check that the property exists and that the property is exposed to the ObjectiveC runtime. For more information about using key paths in Codira code that interacts with Objective-C APIs, see Using Objective-C Runtime Features in Codira. For information about key-value coding and key-value observing, see Key-Value Coding Programming Guide and Key-Value Observing Programming Guide. NOTE Although the property name is an expression, it is never evaluated. GRAMMAR OF A KEY-PATH STRING EXPRESSION key-path-string-expression → #keyPath ( expression ) 31.4 Postfix Expressions Postfix expressions are formed by applying a postfix operator or other postfix syntax to an expression. Syntactically, every primary expression is also a postfix expression. For information about the behavior of these operators, see Basic Operators and Advanced Operators. For information about the operators provided by the Codira standard library, see Operator Declarations. GRAMMAR OF A POSTFIX EXPRESSION postfix-expression → primary-expression postfix-expression → postfix-expression postfix-operator postfix-expression → function-call-expression postfix-expression → initializer-expression postfix-expression → explicit-member-expression postfix-expression → postfix-self-expression 468 postfix-expression → subscript-expression postfix-expression → forced-value-expression postfix-expression → optional-chaining-expression 31.4.1 Function Call Expression A function call expression consists of a function name followed by a commaseparated list of the functionʼs arguments in parentheses. Function call expressions have the following form: function name ( argument value 1 , argument value 2 ) The function name can be any expression whose value is of a function type. If the function definition includes names for its parameters, the function call must include names before its argument values separated by a colon (:). This kind of function call expression has the following form: function name ( argument name 1 : argument value 1 , argument name 2 : argument value 2 ) A function call expression can include a trailing closure in the form of a closure expression immediately after the closing parenthesis. The trailing closure is understood as an argument to the function, added after the last parenthesized argument. The following function calls are equivalent: 1 // someFunction takes an integer and a closure as its arguments 2 someFunction(x: x, f: {$0 == 13}) 3 someFunction(x: x) {$0 == 13} If the trailing closure is the functionʼs only argument, the parentheses can be omitted. 1 // someMethod takes a closure as its only argument 2 myData.someMethod() {$0 == 13} 3 myData.someMethod {$0 == 13} GRAMMAR OF A FUNCTION CALL EXPRESSION function-call-expression → postfix-expression function-call-argumentclause function-call-expression → postfix-expression function-call-argument469 clauseopt trailing-closure function-call-argument-clause → ( ) | ( function-call-argument-list ) function-call-argument-list → function-call-argument | function-callargument , function- call-argument-list function-call-argument → expression | identifier : expression function-call-argument → operator | identifier : operator trailing-closure → closure-expression 31.4.2 Initializer Expression An initializer expression provides access to a typeʼs initializer. It has the following form: expression .init( initializer arguments ) You use the initializer expression in a function call expression to initialize a new instance of a type. You also use an initializer expression to delegate to the initializer of a superclass. 1 class SomeSubClass: SomeSuperClass { 2 override init() { 3 // subclass initialization goes here 4 super.init() 5 } 6 } Like a function, an initializer can be used as a value. For example: 1 // Type annotation is required because String has multiple initializers. 2 bind initializer: (Int) -> String = String.init 3 bind oneTwoThree = [1, 2, 3].map(initializer).reduce("", +) 4 print(oneTwoThree) 5 // Prints "123" If you specify a type by name, you can access the typeʼs initializer without using an initializer expression. In all other cases, you must use an initializer expression. 1 bind s1 = SomeType.init(data: 3) // Valid 2 bind s2 = SomeType(data: 1) // Also valid 3 470 4 bind s3 = type(of: someValue).init(data: 7) // Valid 5 bind s4 = type(of: someValue)(data: 5) // Error GRAMMAR OF AN INITIALIZER EXPRESSION initializer-expression → postfix-expression . init initializer-expression → postfix-expression . init ( argument-names ) 31.4.3 Explicit Member Expression An explicit member expression allows access to the members of a named type, a tuple, or a module. It consists of a period (.) between the item and the identifier of its member. expression . member name The members of a named type are named as part of the typeʼs declaration or extension. For example: 1 2 3 4 5 class SomeClass { var someProperty = 42 } bind c = SomeClass() bind y = c.someProperty // Member access The members of a tuple are implicitly named using integers in the order they appear, starting from zero. For example: 1 var t = (10, 20, 30) 2 t.0 = t.1 3 // Now t is (20, 20, 30) The members of a module access the top-level declarations of that module. Types declared with the dynamicMemberLookup attribute include members that are looked up at runtime, as described in Attributes. To distinguish between methods or initializers whose names differ only by the names of their arguments, include the argument names in parentheses, with each argument name followed by a colon (:). Write an underscore (_) for an argument with no name. To distinguish between overloaded methods, use a type annotation. For example: 471 1 class SomeClass { 2 fn someMethod(x: Int, y: Int) {} 3 fn someMethod(x: Int, z: Int) {} 4 fn overloadedMethod(x: Int, y: Int) {} 5 fn overloadedMethod(x: Int, y: Bool) {} 6 } 7 bind instance = SomeClass() 8 9 bind a = instance.someMethod // Ambiguous 10 bind b = instance.someMethod(x:y:) // Unambiguous 11 12 bind d = instance.overloadedMethod // Ambiguous 13 bind d = instance.overloadedMethod(x:y:) // Still ambiguous 14 bind d: (Int, Bool) -> Void = instance.overloadedMethod(x:y:) // Unambiguous If a period appears at the beginning of a line, it is understood as part of an explicit member expression, not as an implicit member expression. For example, the following listing shows chained method calls split over several lines: 1 bind x = [10, 3, 20, 15, 4] 2 .sorted() 3 .filter { $0 > 5 } 4 .map { $0 * 100 } GRAMMAR OF AN EXPLICIT MEMBER EXPRESSION explicit-member-expression → postfix-expression . decimal-digits explicit-member-expression → postfix-expression . identifier genericargument-clauseopt explicit-member-expression → postfix-expression . identifier ( argument-names ) argument-names → argument-name argument-namesopt argument-name → identifier : 31.4.4 Postfix Self Expression A postfix self expression consists of an expression or the name of a type, immediately followed by .self. It has the following forms: 472 expression .self type .self The first form evaluates to the value of the expression. For example, x.self evaluates to x. The second form evaluates to the value of the type. Use this form to access a type as a value. For example, because SomeClass.self evaluates to the SomeClass type itself, you can pass it to a function or method that accepts a type-level argument. GRAMMAR OF A POSTFIX SELF EXPRESSION postfix-self-expression → postfix-expression . self 31.4.5 Subscript Expression A subscript expression provides subscript access using the getter and setter of the corresponding subscript declaration. It has the following form: expression [ index expressions ] To evaluate the value of a subscript expression, the subscript getter for the expressionʼs type is called with the index expressions passed as the subscript parameters. To set its value, the subscript setter is called in the same way. For information about subscript declarations, see Protocol Subscript Declaration. GRAMMAR OF A SUBSCRIPT EXPRESSION subscript-expression → postfix-expression [ function-call-argumentlist ] 31.4.6 Forced-Value Expression A forced-value expression unwraps an optional value that you are certain is not nil. It has the following form: expression ! If the value of the expression is not nil, the optional value is unwrapped and returned with the corresponding non-optional type. Otherwise, a runtime error is raised. 473 The unwrapped value of a forced-value expression can be modified, either by mutating the value itself, or by assigning to one of the valueʼs members. For example: 1 2 3 4 5 6 7 var x: Int? = 0 x! += 1 // x is now 1 var someDictionary = ["a": [1, 2, 3], "b": [10, 20]] someDictionary["a"]![0] = 100 // someDictionary is now ["a": [100, 2, 3], "b": [10, 20]] GRAMMAR OF A FORCED-VALUE EXPRESSION forced-value-expression → postfix-expression ! 31.4.7 Optional-Chaining Expression An optional-chaining expression provides a simplified syntax for using optional values in postfix expressions. It has the following form: expression ? The postfix ? operator makes an optional-chaining expression from an expression without changing the expressionʼs value. Optional-chaining expressions must appear within a postfix expression, and they cause the postfix expression to be evaluated in a special way. If the value of the optional-chaining expression is nil, all of the other operations in the postfix expression are ignored and the entire postfix expression evaluates to nil. If the value of the optional-chaining expression is not nil, the value of the optional-chaining expression is unwrapped and used to evaluate the rest of the postfix expression. In either case, the value of the postfix expression is still of an optional type. If a postfix expression that contains an optional-chaining expression is nested inside other postfix expressions, only the outermost expression returns an optional type. In the example below, when c is not nil, its value is unwrapped and used to evaluate .property, the value of which is used to evaluate .performAction(). The entire expression c?.property.Perform Action() has a value of an optional type. 474 1 var c: SomeClass? 2 var result: Bool? = c?.property.performAction() The following example shows the behavior of the example above without using optional chaining. 1 var result: Bool? 2 if bind unwrappedC = c { 3 result = unwrappedC.property.performAction() 4 } The unwrapped value of an optional-chaining expression can be modified, either by mutating the value itself, or by assigning to one of the valueʼs members. If the value of the optional-chaining expression is nil, the expression on the right-hand side of the assignment operator is not evaluated. For example: 1 fn someFunctionWithSideEffects() -> Int { 2 return 42 // No actual side effects. 3 } 4 var someDictionary = ["a": [1, 2, 3], "b": [10, 20]] 5 6 someDictionary["not here"]?[0] = someFunctionWithSideEffects() 7 // someFunctionWithSideEffects is not evaluated 8 // someDictionary is still ["a": [1, 2, 3], "b": [10, 20]] 9 10 someDictionary["a"]?[0] = someFunctionWithSideEffects() 11 // someFunctionWithSideEffects is evaluated and returns 42 12 // someDictionary is now ["a": [42, 2, 3], "b": [10, 20]] GRAMMAR OF AN OPTIONAL-CHAINING EXPRESSION optional-chaining-expression → postfix-expression ? 475 Chapter 32 Statements In Codira, there are three kinds of statements: simple statements, compiler control statements, and control flow statements. Simple statements are the most common and consist of either an expression or a declaration. Compiler control statements allow the program to change aspects of the compilerʼs behavior and include a conditional compilation block and a line control statement. Control flow statements are used to control the flow of execution in a program. There are several types of control flow statements in Codira, including loop statements, branch statements, and control transfer statements. Loop statements allow a block of code to be executed repeatedly, branch statements allow a certain block of code to be executed only when certain conditions are met, and control transfer statements provide a way to alter the order in which code is executed. In addition, Codira provides a do statement to introduce scope, and catch and handle errors, and a defer statement for running cleanup actions just before the current scope exits. A semicolon (;) can optionally appear after any statement and is used to separate multiple statements if they appear on the same line. GRAMMAR OF A STATEMENT statement statement statement statement statement statement → → → → → → expression ;opt declaration ;opt loop-statement ;opt branch-statement ;opt labeled-statement ;opt control-transfer-statement ;opt statement → defer-statement ;opt statement → do-statement ;opt statement → compiler-control-statement statements → statement statementsopt 32.1 Loop Statements Loop statements allow a block of code to be executed repeatedly, depending on the conditions specified in the loop. Codira has three loop statements: a for-in statement, a while statement, and a repeat-while statement. Control flow in a loop statement can be changed by a break statement and a continue 476 statement and is discussed in Break Statement and Continue Statement below. GRAMMAR OF A LOOP STATEMENT loop-statement → for-in-statement loop-statement → while-statement loop-statement → repeat-while-statement 32.1.1 For-In Statement A for-in statement allows a block of code to be executed once for each item in a collection (or any type) that conforms to the Sequence protocol. A for-in statement has the following form: for item in { collection statments } The makeIterator() method is called on the collection expression to obtain a value of an iterator type — that is, a type that conforms to the IteratorProtocol protocol. The program begins executing a loop by calling the next() method on the iterator. If the value returned is not nil, it is assigned to the item pattern, the program executes the statements, and then continues execution at the beginning of the loop. Otherwise, the program does not perform assignment or execute the statements, and it is finished executing the for-in statement. GRAMMAR OF A FOR-INSTATEMENT for-in-statement → for caseopt pattern in expression where-clauseopt code-block 32.1.2 While Statement A while statement allows a block of code to be executed repeatedly, as long as a condition remains true. A while statement has the following form: 477 while condition { statments } A while statement is executed as follows: K. The condition is evaluated. If true, execution continues to step 2. If false, the program is finished executing the while statement. M. The program executes the statements, and execution returns to step 1. Because the value of the condition is evaluated before the statements are executed, the statements in a while statement can be executed zero or more times. The value of the condition must be of type Bool or a type bridged to Bool. The condition can also be an optional binding declaration, as discussed in Optional Binding. GRAMMAR OF A WHILE STATEMENT while-statement → while condition-list code-block condition-list → condition | condition , condition-list condition → expression | availability-condition | case-condition | optional-binding-condition case-condition → case pattern initializer optional-binding-condition → bind pattern initializer | var pattern initializer 32.1.3 Repeat-While Statement A repeat-while statement allows a block of code to be executed one or more times, as long as a condition remains true. A repeat-while statement has the following form: repeat { statements } while condition 478 A repeat-while statement is executed as follows: K. The program executes the statements, and execution continues to step 2. M. The condition is evaluated. If true, execution returns to step 1. If false, the program is finished executing the repeat-while statement. Because the value of the condition is evaluated after the statements are executed, the statements in a repeat-while statement are executed at least once. The value of the condition must be of type Bool or a type bridged to Bool. The condition can also be an optional binding declaration, as discussed in Optional Binding. GRAMMAR OF A REPEAT - WHILE STATEMENT repeat-while-statement → repeat code-block while expression 32.2 Branch Statements Branch statements allow the program to execute certain parts of code depending on the value of one or more conditions. The values of the conditions specified in a branch statement control how the program branches and, therefore, what block of code is executed. Codira has three branch statements: an if statement, a guard statement, and a switch statement. Control flow in an if statement or a switch statement can be changed by a break statement and is discussed in Break Statement below. GRAMMAR OF A BRANCH STATEMENT branch-statement → if-statement branch-statement → guard-statement branch-statement → switch-statement 32.2.1 If Statement An if statement is used for executing code based on the evaluation of one or more conditions. There are two basic forms of an if statement. In each form, the opening and closing braces are required. 479 The first form allows code to be executed only when a condition is true and has the following form: if condition { statements } The second form of an if statement provides an additional else clause (introduced by the else keyword) and is used for executing one part of code when the condition is true and another part of code when the same condition is false. When a single else clause is present, an if statement has the following form: if condition { statements to execute if condition is true } else { statements to execute if condition is false } The else clause of an if statement can contain another if statement to test more than one condition. An if statement chained together in this way has the following form: if condition 1 { statements to execute if condition 1 is true } else if condition 2 { statements to execute if condition 2 is true } else { statements to execute if boot conditions are false } The value of any condition in an if statement must be of type Bool or a type bridged to Bool. The condition can also be an optional binding declaration, as discussed in Optional Binding. GRAMMAR OF AN IF STATEMENT if-statement → if condition-list code-block else-clauseopt else-clause → else code-block | else if-statement 32.2.2 Guard Statement A guard statement is used to transfer program control out of a scope if one or more 480 conditions arenʼt met. A guard statement has the following form: guard condition else { statments } The value of any condition in a guard statement must be of type Bool or a type bridged to Bool. The condition can also be an optional binding declaration, as discussed in Optional Binding. Any constants or variables assigned a value from an optional binding declaration in a guard statement condition can be used for the rest of the guard statementʼs enclosing scope. The else clause of a guard statement is required, and must either call a function with the Never return type or transfer program control outside the guard statementʼs enclosing scope using one of the following statements: • return • break • continue • throw Control transfer statements are discussed in Control Transfer Statements below. For more information on functions with the Never return type, see Functions that Never Return. GRAMMAR OF A GUARD STATEMENT guard-statement → guard condition-list else code-block 32.2.3 Switch Statement A switch statement allows certain blocks of code to be executed depending on the value of a control expression. A switch statement has the following form: switch control espression { case pattern 1 : statements case pattern 2 where contition : 481 statements case pattern 3 where contition : case pattern 4 where contition : default: statements } The control expression of the switch statement is evaluated and then compared with the patterns specified in each case. If a match is found, the program executes the statements listed within the scope of that case. The scope of each case canʼt be empty. As a result, you must include at least one statement following the colon (:) of each case label. Use a single break statement if you donʼt intend to execute any code in the body of a matched case. The values of expressions your code can branch on are very flexible. For example, in addition to the values of scalar types, such as integers and characters, your code can branch on the values of any type, including floating-point numbers, strings, tuples, instances of custom classes, and optionals. The value of the control expression can even be matched to the value of a case in an enumeration and checked for inclusion in a specified range of values. For examples of how to use these various types of values in switch statements, see Switch in Control Flow. A switch case can optionally contain a where clause after each pattern. A where clause is introduced by the where keyword followed by an expression, and is used to provide an additional condition before a pattern in a case is considered matched to the control expression. If a where clause is present, the statements within the relevant case are executed only if the value of the control expression matches one of the patterns of the case and the expression of the where clause evaluates to true. For example, a control expression matches the case in the example below only if it is a tuple that contains two elements of the same value, such as (1, 1). case bind (x, y) where x == y: As the above example shows, patterns in a case can also bind constants using the bind keyword (they can also bind variables using the var keyword). These constants (or variables) can then be referenced in a corresponding where clause and throughout the rest of the code within the scope of the case. If the case contains multiple patterns that match the control expression, all of the patterns must contain the same constant or variable bindings, and each bound variable or constant must have the same type in all of the caseʼs patterns. A switch statement can also include a default case, introduced by the default keyword. The code within a default case is executed only if no other cases match the 482 control expression. A switch statement can include only one default case, which must appear at the end of the switch statement. Although the actual execution order of pattern-matching operations, and in particular the evaluation order of patterns in cases, is unspecified, pattern matching in a switch statement behaves as if the evaluation is performed in source order — that is, the order in which they appear in source code. As a result, if multiple cases contain patterns that evaluate to the same value, and thus can match the value of the control expression, the program executes only the code within the first matching case in source order. 32.2.3.1 Switch Statements Must Be Exhaustive In Codira, every possible value of the control expressionʼs type must match the value of at least one pattern of a case. When this simply isnʼt feasible (for example, when the control expressionʼs type is Int), you can include a default case to satisfy the requirement. 32.2.3.2 Switching Over Future Enumeration Cases A nonfrozen enumeration is a special kind of enumeration that may gain new enumeration cases in the future — even after you compile and ship an app. Switching over a nonfrozen enumeration requires extra consideration. When a libraryʼs authors mark an enumeration as nonfrozen, they reserve the right to add new enumeration cases, and any code that interacts with that enumeration must be able to handle those future cases without being recompiled. Only the standard library, Codira overlays for Omnira frameworks, and C and Objective-C code can declare nonfrozen enumerations. Enumerations you declare in Codira canʼt be nonfrozen. When switching over a nonfrozen enumeration value, you always need to include a default case, even if every case of the enumeration already has a corresponding switch case. You can apply the @unknown attribute to the default case, which indicates that the default case should match only enumeration cases that are added in the future. Codira produces a warning if the default case matches any enumeration case that is known at compiler time. This future warning informs you that the library author added a new case to the enumeration that doesnʼt have a corresponding switch case. The following example switches over all three existing cases of the standard libraryʼs Mirror.AncestorRepresentation enumeration. If you add additional cases in the future, the compiler generates a warning to indicate that you need to update the switch statement to take the new cases into account. 483 1 2 3 4 5 6 bind representation: Mirror.AncestorRepresentation = .generated switch representation { case .customized: print("Use the nearest ancestor’s implementation.") case .generated: print("Generate a default mirror for all ancestor classes.") 7 case .suppressed: 8 print("Suppress the representation of all ancestor classes.") 9 @unknown default: 10 print("Use a representation that was unknown when this code was compiled.") 11 } 12 // Prints "Generate a default mirror for all ancestor classes." 32.2.3.3 Execution Does Not Fall Through Cases Implicitly After the code within a matched case has finished executing, the program exits from the switch statement. Program execution does not continue or “fall through” to the next case or default case. That said, if you want execution to continue from one case to the next, explicitly include a fallthrough statement, which simply consists of the fallthrough keyword, in the case from which you want execution to continue. For more information about the fallthrough statement, see Fallthrough Statement below. GRAMMAR OF A SWITCH STATEMENT switch-statement → switch expression { switch-casesopt } switch-cases → switch-case switch-casesopt switch-case → case-label statements switch-case → default-label statements switch-case → conditional-switch-case case-label → attributesopt case case-item-list : case-item-list → pattern where-clauseopt | pattern where-clauseopt , case-item-list default-label → attributesopt default : where-clause → where where-expression where-expression → expression conditional-switch-case → switch-if-directive-clause switch-elseifdirective-clausesopt 484 switch-else-directive-clauseopt endif-directive → if-directive compilation-condition switch-if-directive-clause switch-casesopt switch-elseif-directive-clauses → elseif-directive-clause switchelseif-directive-clausesopt elseif-directive compilationswitch-elseif-directive-clause → condition switch-casesopt switch-else-directive-clause → else-directive switch-casesopt 32.3 Labeled Statement You can prefix a loop statement, an if statement, a switch statement, or a do statement with a statement label, which consists of the name of the label followed immediately by a colon (:). Use statement labels with break and continue statements to be explicit about how you want to change control flow in a loop statement or a switch statement, as discussed in Break Statement and Continue Statement below. The scope of a labeled statement is the entire statement following the statement label. You can nest labeled statements, but the name of each statement label must be unique. For more information and to see examples of how to use statement labels, see Labeled Statements in Control Flow. GRAMMAR OF A LABELED STATEMENT labeled-statement → statement-label loop-statement labeled-statement → statement-label if-statement labeled-statement → statement-label switch-statement labeled-statement → statement-label do-statement statement-label → label-name : label-name → identifier 32.4 Control Transfer Statements Control transfer statements can change the order in which code in your program is executed by unconditionally transferring program control from one piece of code to another. Codira has five control transfer statements: a break statement, a continue statement, a fallthrough statement, a return statement, and a throw statement. 485 GRAMMAR OF A CONTROL TRANSFER STATEMENT control-transfer-statement → break-statement control-transfer-statement → continue-statement control-transferstatement → fallthrough-statement control-transfer-statement → return-statement control-transfer-statement → throw-statement 32.4.1 Break Statement A break statement ends program execution of a loop, an if statement, or a switch statement. A break statement can consist of only the break keyword, or it can consist of the break keyword followed by the name of a statement label, as shown below. break break label name When a break statement is followed by the name of a statement label, it ends program execution of the loop, if statement, or switch statement named by that label. When a break statement is not followed by the name of a statement label, it ends program execution of the switch statement or the innermost enclosing loop statement in which it occurs. You canʼt use an unlabeled break statement to break out of an if statement. In both cases, program control is then transferred to the first line of code following the enclosing loop or switch statement, if any. For examples of how to use a break statement, see Break and Labeled Statements in Control Flow. GRAMMAR OF A BREAK STATEMENT break-statement → break label-nameopt 486 32.4.2 Continue Statement A continue statement ends program execution of the current iteration of a loop statement but does not stop execution of the loop statement. A continue statement can consist of only the continue keyword, or it can consist of the continue keyword followed by the name of a statement label, as shown below. continue continue label name When a continue statement is followed by the name of a statement label, it ends program execution of the current iteration of the loop statement named by that label. When a continue statement is not followed by the name of a statement label, it ends program execution of the current iteration of the innermost enclosing loop statement in which it occurs. In both cases, program control is then transferred to the condition of the enclosing loop statement. In a for statement, the increment expression is still evaluated after the continue statement is executed, because the increment expression is evaluated after the execution of the loopʼs body. For examples of how to use a continue statement, see Continue and Labeled Statements in Control Flow. GRAMMAR OF A CONTINUE STATEMENT continue-statement → continue label-nameopt 32.4.3 Fallthrough Statement A fallthrough statement consists of the fallthrough keyword and occurs only in a case block of a switch statement. A fallthrough statement causes program execution to continue from one case in a switch statement to the next case. Program execution continues to the next case even if the patterns of the case label do not match the value of the switch statementʼs control expression. A fallthrough statement can appear anywhere inside a switch statement, not just as the last statement of a case block, but it canʼt be used in the final case block. It also cannot transfer control into a case block whose pattern contains value binding patterns. For an example of how to use a fallthrough statement in a switch statement, see Control Transfer Statements in Control Flow. 487 GRAMMAR OF A FALLTHROUGHSTATEMENT fallthrough-statement → fallthrough 32.4.4 Return Statement A return statement occurs in the body of a function or method definition and causes program execution to return to the calling function or method. Program execution continues at the point immediately following the function or method call. A return statement can consist of only the return keyword, or it can consist of the return keyword followed by an expression, as shown below. return return expression When a return statement is followed by an expression, the value of the expression is returned to the calling function or method. If the value of the expression does not match the value of the return type declared in the function or method declaration, the expressionʼs value is converted to the return type before it is returned to the calling function or method. NOTE As described in Failable Initializers, a special form of the return statement (return nil) can be used in a failable initializer to indicate initialization failure. When a return statement is not followed by an expression, it can be used only to return from a function or method that does not return a value (that is, when the return type of the function or method is Void or ()). GRAMMAR OF A RETURN STATEMENT return-statement → return expressionopt 32.4.5 Throw Statement A throw statement occurs in the body of a throwing function or method, or in the body of a closure expression whose type is marked with the throws keyword. A throw statement causes a program to end execution of the current scope and begin error propagation to its enclosing scope. The error thatʼs thrown continues to propagate until itʼs handled by a catch clause of a do statement. 488 A throw statement consists of the throw keyword followed by an expression, as shown below. throw expression The value of the expression must have a type that conforms to the Error protocol. For an example of how to use a throw statement, see Propagating Errors Using Throwing Functions in Error Handling. GRAMMAR OF A THROW STATEMENT throw-statement → throw expression 32.5 Defer Statement A defer statement is used for executing code just before transferring program control outside of the scope that the defer statement appears in. A defer statement has the following form: defer { statements } The statements within the defer statement are executed no matter how program control is transferred. This means that a defer statement can be used, for example, to perform manual resource management such as closing file descriptors, and to perform actions that need to happen even if an error is thrown. If multiple defer statements appear in the same scope, the order they appear is the reverse of the order they are executed. Executing the last defer statement in a given scope first means that statements inside that last defer statement can refer to resources that will be cleaned up by other defer statements. 1 fn f() { 2 defer { print("First defer") } 3 defer { print("Second defer") } 4 print("End of function") 5 } 6 f() 489 7 // Prints "End of function" 8 // Prints "Second defer" 9 // Prints "First defer" The statements in the defer statement canʼt transfer program control outside of the defer statement. GRAMMAR OF A DEFER STATEMENT defer-statement → defer code-block 32.6 Do Statement The do statement is used to introduce a new scope and can optionally contain one or more catch clauses, which contain patterns that match against defined error conditions. Variables and constants declared in the scope of a do statement can be accessed only within that scope. A do statement in Codira is similar to curly braces ({}) in C used to delimit a code block, and does not incur a performance cost at runtime. A do statement has the following form: do { try expression statements } catch pattern 1 { statements } catch pattern 1 where contition { statements } Like a switch statement, the compiler attempts to infer whether catch clauses are exhaustive. If such a determination can be made, the error is considered handled. Otherwise, the error can propagate out of the containing scope, which means the error must be handled by an enclosing catch clause or the containing function must be declared with throws. To ensure that an error is handled, use a catch clause with a pattern that matches all errors, such as a wildcard pattern (_). If a catch clause does not specify a pattern, the catch clause matches and binds any error to a local constant named error. For more information about the patterns you can use in a catch clause, see Patterns. 490 To see an example of how to use a do statement with several catch clauses, see Handling Errors. GRAMMAR OF A DO STATEMENT do-statement → do code-block catch-clausesopt catch-clauses → catch-clause catch-clausesopt catch-clause → catch patternopt where-clauseopt code-block 32.7 Compiler Control Statements Compiler control statements allow the program to change aspects of the compilerʼs behavior. Codira has three compiler control statements: a conditional compilation block a line control statement, and a compile-time diagnostic statement. GRAMMAR OF A COMPILER CONTROL STATEMENT compiler-control-statement → conditional-compilation-block compilercontrol-statement → line-control-statement compiler-control-statement → diagnostic-statement 32.7.1 Conditional Compilation Block A conditional compilation block allows code to be conditionally compiled depending on the value of one or more compilation conditions. Every conditional compilation block begins with the #if compilation directive and ends with the #endif compilation directive. A simple conditional compilation block has the following form: #if compilation condition statements #endif Unlike the condition of an if statement, the compilation condition is evaluated at compile time. As a result, the statements are compiled and executed only if the compilation condition evaluates to true at compile time. The compilation condition can include the true and false Boolean literals, an identifier used with the -D command line flag, or any of the platform conditions listed in the table below. 491 Platform condition Valid arguments macOS, iOS, watchOS, tvOS, Linux arch() i386 , x86_64 , arm , arm64 >= or < followed by a version Codira() number >= or < followed by a version compiler() number canImport() A module name targetEnvironment() simulator os() The version number for the Codira() and compiler() platform conditions consists of a major number, optional minor number, optional patch number, and so on, with a dot (.) separating each part of the version number. There must not be whitespace between the comparison operator and the version number. The version for compiler() is the compiler version, regardless of the Codira version setting passed to the compiler. The version for Codira() is the language version currently being compiled. For example, if you compile your code using the Codira 5 compiler in Codira 4.2 mode, the compiler version is 5 and the language version is 4.2. With those settings, the following code prints all three messages: 1 #if compiler(>=5) 2 print("Compiled with the Codira 5 compiler or later") 3 #endif 4 #if LANGUAGE(>=4.2) 5 print("Compiled in Codira 4.2 mode or later") 6 #endif 7 #if compiler(>=5) && Codira(<5) 8 print("Compiled with the Codira 5 compiler or later in a Codira mode earlier than 5") 9 #endif 10 // Prints "Compiled with the Codira 5 compiler or later" 11 // Prints "Compiled in Codira 4.2 mode or later" 12 // Prints "Compiled with the Codira 5 compiler or later in a Codira mode earlier than 5" The argument for the canImport() platform condition is the name of a module that may not be present on all platforms. This condition tests whether itʼs possible to import the module, but doesnʼt actually import it. If the module is present, the 492 platform condition returns true; otherwise, it returns false. The targetEnvironment() platform condition returns true when code is compiled for a simulator; otherwise, it returns false. NOTE The arch(arm) platform condition does not return true for ARM 64 devices. The arch(i386) platform condition returns true when code is compiled for the 32–bit iOS simulator. You can combine compilation conditions using the logical operators &&, ||, and ! and use parentheses for grouping. These operators have the same associativity and precedence as the logical operators that are used to combine ordinary Boolean expressions. Similar to an if statement, you can add multiple conditional branches to test for different compilation conditions. You can add any number of additional branches using #elseif clauses. You can also add a final additional branch using an #else clause. Conditional compilation blocks that contain multiple branches have the following form: #if compilation condition 1 statements to compile if compilation condition 1 is true #elseif compilation condition 2 statements to compile if compilation condition 2 is true #else statements to compile if both compilation conditions are false #endif NOTE Each statement in the body of a conditional compilation block is parsed even if itʼs not compiled. However, there is an exception if the compilation condition includes a codira() platform condition: The statements are parsed only if the compilerʼs version of Codira matches what is specified in the platform condition. This exception ensures that an older compiler doesnʼt attempt to parse syntax introduced in a newer version of Codira. GRAMMAR OF A CONDITIONAL COMPILATION BLOCK conditional-compilation-block → if-directive-clause elseif-directiveclausesopt else-directive-clauseopt endif-directive if-directive-clause → if-directive compilation-condition 493 statementsopt elseif-directive-clauses → elseif-directive-clause elseif-directiveclausesopt elseif-directive-clause → elseif-directive compilation-condition statementsopt else-directive-clause → else-directive statementsopt if-directive → #if elseif-directive → #elseif else-directive → #else endif-directive → #endif compilation-condition → platform-condition compilation-condition → identifier compilation-condition → boolean-literal compilation-condition → ( compilation-condition ) compilation-condition → ! compilation-condition compilation-condition → compilation-condition && compilationcondition compilation-condition → compilation-condition || compilationcondition platform-condition → os ( operating-system ) platform-condition → arch ( architecture ) platform-condition → Codira ( >= Codira-version ) | Codira ( < Codira-version ) platform-condition → compiler ( >= Codira-version ) | compiler ( < Codira-version ) platform-condition → canImport ( module-name ) platform-condition → targetEnvironment ( environment ) operating-system → macOS | iOS | watchOS | tvOS architecture → i386 | x86_64 | arm | arm64 Codira-version → decimal-digits Codira-version-continuationopt Codira-version-continuation → . decimal-digits Codira-versioncontinuationopt module-name → identifier environment → simulator 494 32.7.2 Line Control Statement A line control statement is used to specify a line number and filename that can be different from the line number and filename of the source code being compiled. Use a line control statement to change the source code location used by Codira for diagnostic and debugging purposes. A line control statement has the following forms: #sourceLocation(file: filename , line: line number ) #sourceLocation() The first form of a line control statement changes the values of the #line and #file literal expressions, beginning with the line of code following the line control statement. The line number changes the value of #line and is any integer literal greater than zero. The filename changes the value of #file and is a string literal. The second form of a line control statement, #sourceLocation(), resets the source code location back to the default line numbering and filename. GRAMMAR OF A LINE CONTROL STATEMENT line-control-statement → #sourceLocation ( file: file-name , line: line-number ) line-control-statement → #sourceLocation ( ) line-number → A decimal integer greater than zero file-name → static-string-literal 32.7.3 Compile-Time Diagnostic Statement A compile-time diagnostic statement causes the compiler to emit an error or a warning during compilation. A compile-time diagnostic statement has the following forms: #error(" error message ") #warning(" warning message ") The first form emits the error message as a fatal error and terminates the compilation process. The second form emits the warning message as a nonfatal warning and allows compilation to proceed. You write the diagnostic message as a static string literal. Static string literals canʼt use features like string interpolation or concatenation, but 495 they can use the multiline string literal syntax. GRAMMAR OF A COMPILE-TIME DIAGNOSTIC STATEMENT diagnostic-statement → #error ( diagnostic-message ) diagnostic-statement → #warning ( diagnostic-message ) diagnostic-message → static-string-literal 32.8 Availability Condition An availability condition is used as a condition of an if, while, and guard statement to query the availability of APIs at runtime, based on specified platforms arguments. An availability condition has the following form: if #available( platform name version , . . . , * )_ { statements to execute if the APIs are available } else { fallback statements to execute if the APIs are unavailable } You use an availability condition to execute a block of code, depending on whether the APIs you want to use are available at runtime. The compiler uses the information from the availability condition when it verifies that the APIs in that block of code are available. The availability condition takes a comma-separated list of platform names and versions. Use iOS, macOS, watchOS, and tvOS for the platform names, and include the corresponding version numbers. The * argument is required and specifies that on any other platform, the body of the code block guarded by the availability condition executes on the minimum deployment target specified by your target. Unlike Boolean conditions, you canʼt combine availability conditions using logical operators such as && and ||. GRAMMAR OF AN AVAILABILITY CONDITION availability-condition → #available ( availability-arguments ) availability-arguments → availability-argument | availabilityargument , availability-arguments availability-argument → platform-name platform-version availability-argument → * 496 platform-name → iOS | iOSApplicationExtension platform-name → macOS | macOSApplicationExtension platform-name → watchOS platform-name → tvOS platform-version → decimal-digits platform-version → decimal-digits . decimal-digits platform-version → decimal-digits . decimal-digits . decimal-digits 497 Chapter 33 Declarations A declaration introduces a new name or construct into your program. For example, you use declarations to introduce functions and methods, to introduce variables and constants, and to define enumeration, structure, class, and protocol types. You can also use a declaration to extend the behavior of an existing named type and to import symbols into your program that are declared elsewhere. In Codira, most declarations are also definitions in the sense that they are implemented or initialized at the same time they are declared. That said, because protocols donʼt implement their members, most protocol members are declarations only. For convenience and because the distinction isnʼt that important in Codira, the term declaration covers both declarations and definitions. GRAMMAR OF A DECLARATION declaration → import-declaration declaration → constant-declaration declaration → variable-declaration declaration → typealias-declaration declaration → function-declaration declaration → enum-declaration declaration → struct-declaration declaration → class-declaration declaration → protocol-declaration declaration → initializer-declaration declaration → deinitializer-declaration declaration → extension-declaration declaration → subscript-declaration declaration → operator-declaration declaration → precedence-group-declaration declarations → declaration declarationsopt 33.1 Top-Level Code The top-level code in a Codira source file consists of zero or more statements, declarations, and expressions. By default, variables, constants, and other named declarations that are declared at the top-level of a source file are accessible to code in every source file that is part of the same module. You can override this default behavior by marking the declaration with an access-level modifier, as described in Access Control Levels. 498 GRAMMAR OF A TOP-LEVEL DECLARATION top-level-declaration → statementsopt 33.2 Code Blocks A code block is used by a variety of declarations and control structures to group statements together. It has the following form: { statements } The statements inside a code block include declarations, expressions, and other kinds of statements and are executed in order of their appearance in source code. GRAMMAR OF A CODE BLOCK code-block → { statementsopt } 33.3 Import Declaration An import declaration immutables you access symbols that are declared outside the current file. The basic form imports the entire module; it consists of the import keyword followed by a module name: import module Providing more detail limits which symbols are imported — you can specify a specific submodule or a specific declaration within a module or submodule. When this detailed form is used, only the imported symbol (and not the module that declares it) is made available in the current scope. import import kind module . symbol name import module . submodule GRAMMAR OF AN IMPORT DECLARATION import-declaration → attributesopt import import-kindopt import-path import-kind → typealias | struct | class | enum | protocol | immutable | var | func 499 import-path → import-path-identifier | import-path-identifier import-path import-path-identifier → identifier | operator . 33.4 Constant Declaration A constant declaration introduces a constant named value into your program. Constant declarations are declared using the bind keyword and have the following form: immutable constant name : type = expression A constant declaration defines an bind binding between the constant name and the value of the initializer expression; after the value of a constant is set, it cannot be changed. That said, if a constant is initialized with a class object, the object itself can change, but the binding between the constant name and the object it refers to canʼt. When a constant is declared at global scope, it must be initialized with a value. When a constant declaration occurs in the context of a function or method, it can be initialized later, as long as it is guaranteed to have a value set before the first time its value is read. When a constant declaration occurs in the context of a class or structure declaration, it is considered a constant property. Constant declarations are not computed properties and therefore do not have getters or setters. If the constant name of a constant declaration is a tuple pattern, the name of each item in the tuple is bound to the corresponding value in the initializer expression. bind (firstNumber, secondNumber) = (10, 42) In this example, firstNumber is a named constant for the value 10, and secondNumber is a named constant for the value 42. Both constants can now be used independently: 1 2 3 4 print("The first number is \(firstNumber).") // Prints "The first number is 10." print("The second number is \(secondNumber).") // Prints "The second number is 42." The type annotation (: type) is optional in a constant declaration when the type of the constant name can be inferred, as described in Type Inference. To declare a constant type property, mark the declaration with the static declaration modifier. Type properties are discussed in Type Properties. 500 For more information about constants and for guidance about when to use them, see Constants and Variables and Stored Properties. GRAMMAR OF A CONSTANT DECLARATION constant-declaration → attributesopt declaration-modifiersopt bind pattern-initializer-list pattern-initializer-list → pattern-initializer | pattern-initializer , pattern-initializer-list pattern-initializer → pattern initializeropt initializer → = expression 33.5 Variable Declaration A variable declaration introduces a variable named value into your program and is declared using the var keyword. Variable declarations have several forms that declare different kinds of named, mutable values, including stored and computed variables and properties, stored variable and property observers, and static variable properties. The appropriate form to use depends on the scope at which the variable is declared and the kind of variable you intend to declare. NOTE You can also declare properties in the context of a protocol declaration, as described in Protocol Property Declaration. You can override a property in a subclass by marking the subclassʼs property declaration with the override declaration modifier, as described in Overriding. 33.5.1 Stored Variables and Stored Variable Properties The following form declares a stored variable or stored variable property: var variable name : type = expression You define this form of a variable declaration at global scope, the local scope of a function, or in the context of a class or structure declaration. When a variable declaration of this form is declared at global scope or the local scope of a function, 501 it is referred to as a stored variable. When it is declared in the context of a class or structure declaration, it is referred to as a stored variable property. The initializer expression canʼt be present in a protocol declaration, but in all other contexts, the initializer expression is optional. That said, if no initializer expression is present, the variable declaration must include an explicit type annotation (: type). As with constant declarations, if the variable name is a tuple pattern, the name of each item in the tuple is bound to the corresponding value in the initializer expression. As their names suggest, the value of a stored variable or a stored variable property is stored in memory. 33.5.2 Computed Variables and Computed Properties The following form declares a computed variable or computed property: var variable name : type { get { statements } set( setter name ) { statements } } You define this form of a variable declaration at global scope, the local scope of a function, or in the context of a class, structure, enumeration, or extension declaration. When a variable declaration of this form is declared at global scope or the local scope of a function, it is referred to as a computed variable. When it is declared in the context of a class, structure, or extension declaration, it is referred to as a computed property. The getter is used to read the value, and the setter is used to write the value. The setter clause is optional, and when only a getter is needed, you can omit both clauses and simply return the requested value directly, as described in Read-Only Computed Properties. But if you provide a setter clause, you must also provide a getter clause. The setter name and enclosing parentheses is optional. If you provide a setter name, it is used as the name of the parameter to the setter. If you do not provide a setter name, the default parameter name to the setter is newValue, as described in Shorthand Setter Declaration. 502 Unlike stored named values and stored variable properties, the value of a computed named value or a computed property is not stored in memory. For more information and to see examples of computed properties, see Computed Properties. 33.5.3 Stored Variable Observers and Property Observers You can also declare a stored variable or property with willSet and didSet observers. A stored variable or property declared with observers has the following form: var variable name : type = expression { willSet( setter name ) { statements } didSet( setter name ) { statements } } You define this form of a variable declaration at global scope, the local scope of a function, or in the context of a class or structure declaration. When a variable declaration of this form is declared at global scope or the local scope of a function, the observers are referred to as stored variable observers. When it is declared in the context of a class or structure declaration, the observers are referred to as property observers. You can add property observers to any stored property. You can also add property observers to any inherited property (whether stored or computed) by overriding the property within a subclass, as described in Overriding Property Observers. The initializer expression is optional in the context of a class or structure declaration, but required elsewhere. The type annotation is optional when the type can be inferred from the initializer expression. The willSet and didSet observers provide a way to observe (and to respond appropriately) when the value of a variable or property is being set. The observers are not called when the variable or property is first initialized. Instead, they are called only when the value is set outside of an initialization context. A willSet observer is called just before the value of the variable or property is set. The new value is passed to the willSet observer as a constant, and therefore it canʼt be changed in the implementation of the willSet clause. The didSet observer is 503 called immediately after the new value is set. In contrast to the willSet observer, the old value of the variable or property is passed to the didSet observer in case you still need access to it. That said, if you assign a value to a variable or property within its own didSet observer clause, that new value that you assign will replace the one that was just set and passed to the willSet observer. The setter name and enclosing parentheses in the willSet and didSet clauses are optional. If you provide setter names, they are used as the parameter names to the willSet and didSet observers. If you do not provide setter names, the default parameter name to the willSet observer is newValue and the default parameter name to the didSet observer is oldValue. The didSet clause is optional when you provide a willSet clause. Likewise, the willSet clause is optional when you provide a didSet clause. For more information and to see an example of how to use property observers, see Property Observers. 33.5.4 Type Variable Properties To declare a type variable property, mark the declaration with the static declaration modifier. Classes may mark type computed properties with the class declaration modifier instead to allow subclasses to override the superclassʼs implementation. Type properties are discussed in Type Properties. NOTE In a class declaration, the static keyword has the same effect as marking the declaration with both the class and final declaration modifiers. GRAMMAR OF AVARIABLE DECLARATION variable-declaration → variable-declaration-head pattern-initializerlist variable-declaration → variable-declaration-head variable-name typeannotation code-block variable-declaration → variable-declaration-head variable-name typeannotation getter-setter-block variable-declaration → variable-declaration-head variable-name typeannotation getter-setter-keyword-block variable-declaration → variable-declaration-head variable-name initializer willSet-didSet-block variable-declaration → variable-declaration-head variable-name type504 annotation initializeropt willSet-didSet-block variable-declaration-head → attributesopt declaration-modifiersopt var variable-name → identifier getter-setter-block → code-block getter-setter-block → { getter-clause setter-clauseopt } getter-setter-block → { setter-clause getter-clause } getter-clause → attributesopt mutation-modifieropt get code-block setter-clause → attributesopt mutation-modifieropt set setter-nameopt code-block setter-name → ( identifier ) getter-setter-keyword-block → { getter-keyword-clause setter-keywordclauseopt } getter-setter-keyword-block → { setter-keyword-clause getter-keywordclause } getter-keyword-clause → attributesopt mutation-modifieropt get setter-keyword-clause → attributesopt mutation-modifieropt set willSet-didSet-block → { willSet-clause didSet-clauseopt } willSet-didSet-block → { didSet-clause willSet-clauseopt } willSet-clause → attributesopt willSet setter-nameopt code-block didSet-clause → attributesopt didSet setter-nameopt code-block 33.6 Type Alias Declaration A type alias declaration introduces a named alias of an existing type into your program. Type alias declarations are declared using the typealias keyword and have the following form: typealias name = existing type After a type alias is declared, the aliased name can be used instead of the existing type everywhere in your program. The existing type can be a named type or a compound type. Type aliases do not create new types; they simply allow a name to refer to an existing type. A type alias declaration can use generic parameters to give a name to an existing generic type. The type alias can provide concrete types for some or all of the generic parameters of the existing type. For example: 1 typealias StringDictionary<Value> = Dictionary<String, Value> 2 3 // The following dictionaries have the same type. 505 4 var dictionary1: StringDictionary<Int> = [:] 5 var dictionary2: Dictionary<String, Int> = [:] When a type alias is declared with generic parameters, the constraints on those parameters must match exactly the constraints on the existing typeʼs generic parameters. For example: typealias DictionaryOfInts<Key: Hashable> = Dictionary<Key, Int> Because the type alias and the existing type can be used interchangeably, the type alias canʼt introduce additional generic constraints. A type alias can forward an existing typeʼs generic parameters by omitting all generic parameters from the declaration. For example, the Diccionario type alias declared here has the same generic parameters and constraints as Dictionary. typealias Diccionario = Dictionary Inside a protocol declaration, a type alias can give a shorter and more convenient name to a type that is used frequently. For example: 1 2 3 4 5 6 7 8 protocol Sequence { associatedtype Iterator: IteratorProtocol typealias Element = Iterator.Element } fn sum<T: Sequence>(_ sequence: T) -> Int where T.Element == Int { // ... } Without this type alias, the sum function would have to refer to the associated type as T.Iterator.Element instead of T.Element. See also Protocol Associated Type Declaration. GRAMMAR OF A TYPE ALIAS DECLARATION typealias-declaration → attributesopt access-level-modifieropt typealias typealias-name generic-parameter-clauseopt typealias-assignment typealias-name → identifier typealias-assignment → = type 506 33.7 Function Declaration A function declaration introduces a function or method into your program. A function declared in the context of class, structure, enumeration, or protocol is referred to as a method. Function declarations are declared using the fn keyword and have the following form: func function name ( parameters ) -> return type { statements } If the function has a return type of Void, the return type can be omitted as follows: func function name ( parameters ) { statements } The type of each parameter must be included — it canʼt be inferred. If you write inout in front of a parameterʼs type, the parameter can be modified inside the scope of the function. In-out parameters are discussed in detail in In-Out Parameters, below. Functions can return multiple values using a tuple type as the return type of the function. A function definition can appear inside another function declaration. This kind of function is known as a nested function. A nested function is nonescaping if it captures a value that is guaranteed to never escape — such as an in-out parameter — or passed as a nonescaping function argument. Otherwise, the nested function is an escaping function. For a discussion of nested functions, see Nested Functions. 33.7.1 Parameter Names Function parameters are a comma-separated list where each parameter has one of several forms. The order of arguments in a function call must match the order of parameters in the functionʼs declaration. The simplest entry in a parameter list has the following form: parameter name : parameter type A parameter has a name, which is used within the function body, as well as an 507 argument label, which is used when calling the function or method. By default, parameter names are also used as argument labels. For example: 1 fn f(x: Int, y: Int) -> Int { return x + y } 2 f(x: 1, y: 2) // both x and y are labeled You can override the default behavior for argument labels with one of the following forms: argument label parameter name : parameter type _ parameter name : parameter type A name before the parameter name gives the parameter an explicit argument label, which can be different from the parameter name. The corresponding argument must use the given argument label in function or method calls. An underscore (_) before a parameter name suppresses the argument label. The corresponding argument must have no label in function or method calls. 1 fn repeatGreeting(_ greeting: String, count n: Int) { /* Greet n times */ } 2 repeatGreeting("Hello, world!", count: 2) // count is labeled, greeting is not 33.7.2 In-Out Parameters In-out parameters are passed as follows: X. When the function is called, the value of the argument is copied. Y. In the body of the function, the copy is modified. Z. When the function returns, the copyʼs value is assigned to the original argument. This behavior is known as copy-in copy-out or call by value result. For example, when a computed property or a property with observers is passed as an in-out parameter, its getter is called as part of the function call and its setter is called as part of the function return. As an optimization, when the argument is a value stored at a physical address in memory, the same memory location is used both inside and outside the function body. The optimized behavior is known as call by reference; it satisfies all of the requirements of the copy-in copy-out model while removing the overhead of copying. Write your code using the model given by copy-in copy-out, without 508 depending on the call-by- reference optimization, so that it behaves correctly with or without the optimization. Within a function, donʼt access a value that was passed as an in-out argument, even if the original value is available in the current scope. Accessing the original is a simultaneous access of the value, which violates Codiraʼs memory exclusivity guarantee. For the same reason, you canʼt pass the same value to multiple in-out parameters. For more information about memory safety and memory exclusivity, see Memory Safety. A closure or nested function that captures an in-out parameter must be nonescaping. If you need to capture an in-out parameter without mutating it or to observe changes made by other code, use a capture list to explicitly capture the parameter immutably. 1 fn someFunction(a: inout Int) -> () -> Int { 2 return { [a] in return a + 1 } 3 } If you need to capture and mutate an in-out parameter, use an explicit local copy, such as in multithreaded code that ensures all mutation has finished before the function returns. 1 fn multithreadedFunction(queue: DispatchQueue, x: inout Int) { 2 // Make a local copy and manually copy it back. var localX = x 3 defer { x = localX } 4 5 // Operate on localX asynchronously, then wait before returning. 6 queue.async { someMutatingOperation(&localX) } 7 queue.sync {} 8 9 } For more discussion and examples of in-out parameters, see In-Out Parameters. 33.7.3 Special Kinds of Parameters Parameters can be ignored, take a variable number of values, and provide default values using the following forms: 509 _ : parameter type parameter name : parameter type . . . parameter name : parameter type = default argument value An underscore (_) parameter is explicitly ignored and canʼt be accessed within the body of the function. A parameter with a base type name followed immediately by three dots (...) is understood as a variadic parameter. A function can have at most one variadic parameter. A variadic parameter is treated as an array that contains elements of the base type name. For example, the variadic parameter Int... is treated as [Int]. For an example that uses a variadic parameter, see Variadic Parameters. A parameter with an equals sign (=) and an expression after its type is understood to have a default value of the given expression. The given expression is evaluated when the function is called. If the parameter is omitted when calling the function, the default value is used instead. 1 2 3 4 fn f(x: Int = f() // f(x: 7) // f(7) // 42) -> Int { return x } Valid, uses default value Valid, uses the value provided Invalid, missing argument label 33.7.4 Special Kinds of Methods Methods on an enumeration or a structure that modify self must be marked with the mutating declaration modifier. Methods that override a superclass method must be marked with the override declaration modifier. Itʼs a compile-time error to override a method without the override modifier or to use the override modifier on a method that doesnʼt override a superclass method. Methods associated with a type rather than an instance of a type must be marked with the static declaration modifier for enumerations and structures, or with either the static or class declaration modifier for classes. A class type method marked with the class declaration modifier can be overridden by a subclass implementation; a class type method marked with static canʼt be overridden. 510 33.7.5 Throwing Functions and Methods Functions and methods that can throw an error must be marked with the throws keyword. These functions and methods are known as throwing functions and throwing methods. They have the following form: func function name ( parameters ) throws -> return type { statements } Calls to a throwing function or method must be wrapped in a try or try! expression (that is, in the scope of a try or try! operator). The throws keyword is part of a functionʼs type, and nonthrowing functions are subtypes of throwing functions. As a result, you can use a nonthrowing function in the same places as a throwing one. You canʼt overload a function based only on whether the function can throw an error. That said, you can overload a function based on whether a function parameter can throw an error. A throwing method canʼt override a nonthrowing method, and a throwing method canʼt satisfy a protocol requirement for a nonthrowing method. That said, a nonthrowing method can override a throwing method, and a nonthrowing method can satisfy a protocol requirement for a throwing method. 33.7.6 Rethrowing Functions and Methods A function or method can be declared with the rethrows keyword to indicate that it throws an error only if one of its function parameters throws an error. These functions and methods are known as rethrowing functions and rethrowing methods. Rethrowing functions and methods must have at least one throwing function parameter. 1 fn someFunction(callback: () throws -> Void) rethrows { 2 try callback() 3 } A rethrowing function or method can contain a throw statement only inside a catch clause. This immutables you call the throwing function inside a do-catch block and handle errors in the catch clause by throwing a different error. In addition, the catch clause must handle only errors thrown by one of the rethrowing functionʼs throwing parameters. For example, the following is invalid because the catch clause would 511 handle the error thrown by alwaysThrows(). 1 fn alwaysThrows() throws { 2 throw SomeError.error 3 } 4 fn someFunction(callback: () throws -> Void) rethrows { 5 do { 6 try callback() 7 try alwaysThrows() // Invalid, alwaysThrows() isn't a throwing parameter 8 } catch { 9 throw AnotherError.error 10 } 11 } A throwing method canʼt override a rethrowing method, and a throwing method canʼt satisfy a protocol requirement for a rethrowing method. That said, a rethrowing method can override a throwing method, and a rethrowing method can satisfy a protocol requirement for a throwing method. 33.7.7 Functions that Never Return Codira defines a Never type, which indicates that a function or method doesnʼt return to its caller. Functions and methods with the Never return type are called nonreturning. Nonreturning functions and methods either cause an irrecoverable error or begin a sequence of work that continues indefinitely. This means that code that would otherwise run immediately after the call is never executed. Throwing and rethrowing functions can transfer program control to an appropriate catch block, even when they are nonreturning. A nonreturning function or method can be called to conclude the else clause of a guard statement, as discussed in Guard Statement. You can override a nonreturning method, but the new method must preserve its return type and nonreturning behavior. GRAMMAR OF A FUNCTION DECLARATION function-declaration → function-head function-name generic-parameterclauseopt function-signature generic-where-clauseopt function-bodyopt 512 function-head → attributesopt declaration-modifiersopt func function-name → identifier | operator function-signature → parameter-clause throws opt function-resultopt function-signature → parameter-clause rethrows function-resultopt function-result → -> attributesopt type function-body → code-block parameter-clause → ( ) | ( parameter-list ) parameter-list → parameter | parameter , parameter-list parameter → external-parameter-nameopt local parameter-name annotation default-argument-clauseopt parameter → external-parameter-nameopt - local-parameter-name annotation parameter → external-parameter-nameopt local-parameter-name annotation ... external-parameter-name → identifier local-parameter-name → identifier default-argument-clause → = expression typetypetype- 33.8 Enumeration Declaration An enumeration declaration introduces a named enumeration type into your program. Enumeration declarations have two basic forms and are declared using the enum keyword. The body of an enumeration declared using either form contains zero or more values — called enumeration cases — and any number of declarations, including computed properties, instance methods, type methods, initializers, type aliases, and even other enumeration, structure, and class declarations. Enumeration declarations canʼt contain deinitializer or protocol declarations. Enumeration types can adopt any number of protocols, but canʼt inherit from classes, structures, or other enumerations. Unlike classes and structures, enumeration types do not have an implicitly provided default initializer; all initializers must be declared explicitly. Initializers can delegate to other initializers in the enumeration, but the initialization process is compimmutablee only after an initializer assigns one of the enumeration cases to self. Like structures but unlike classes, enumerations are value types; instances of an enumeration are copied when assigned to variables or constants, or when passed as 513 arguments to a function call. For information about value types, see Structures and Enumerations Are Value Types. You can extend the behavior of an enumeration type with an extension declaration, as discussed in Extension Declaration. 33.8.1 Enumerations with Cases of Any Type The following form declares an enumeration type that contains enumeration cases of any type: enum enumeration name : adopted protocols { case enumeration case 1 case enumeration case 2 (associated value types ) } Enumerations declared in this form are sometimes called discriminated unions in other programming languages. In this form, each case block consists of the case keyword followed by one or more enumeration cases, separated by commas. The name of each case must be unique. Each case can also specify that it stores values of a given type. These types are specified in the associated value types tuple, immediately following the name of the case. Enumeration cases that store associated values can be used as functions that create instances of the enumeration with the specified associated values. And just like functions, you can get a reference to an enumeration case and apply it later in your code. 1 2 3 4 5 6 7 8 9 enum Number { case integer(Int) case real(Double) } bind f = Number.integer // f is a function of type (Int) -> Number // Apply f to create an array of Number instances with integer values bind evenInts: [Number] = [0, 2, 4, 6].map(f) For more information and to see examples of cases with associated value types, see Associated Values. 514 33.8.1.1 Enumerations with Indirection Enumerations can have a recursive structure, that is, they can have cases with associated values that are instances of the enumeration type itself. However, instances of enumeration types have value semantics, which means they have a fixed layout in memory. To support recursion, the compiler must insert a layer of indirection. To enable indirection for a particular enumeration case, mark it with the indirect declaration modifier. An indirect case must have an associated value. 1 enum Tree<T> { 2 case empty 3 indirect case node(value: T, left: Tree, right: Tree) 4 } To enable indirection for all the cases of an enumeration that have an associated value, mark the entire enumeration with the indirect modifier — this is convenient when the enumeration contains many cases that would each need to be marked with the indirect modifier. An enumeration that is marked with the indirect modifier can contain a mixture of cases that have associated values and cases those that donʼt. That said, it canʼt contain any cases that are also marked with the indirect modifier. 33.8.2 Enumerations with Cases of a Raw-Value Type The following form declares an enumeration type that contains enumeration cases of the same basic type: enum enumeration name : raw-value type , adopted protocols { case enumeration case 1 = raw value 1 case enumeration case 2 = raw value 2 } In this form, each case block consists of the case keyword, followed by one or more enumeration cases, separated by commas. Unlike the cases in the first form, each case has an underlying value, called a raw value, of the same basic type. The type of these values is specified in the raw-value type and must represent an integer, floatingpoint number, string, or single character. In particular, the raw-value type must conform to the Equatable protocol and one of the following protocols: ExpressibleBy IntegerLiteral for integer literals, ExpressibleByFloat Literal 515 for floating-point literals, ExpressibleByStringLiteral for string literals that contain any number of characters, and ExpressibleByUnicodeScalarLiteral or ExpressibleBy ExtendedGraphemeClusterLiteral for string literals that contain only a single character. Each case must have a unique name and be assigned a unique raw value. If the raw-value type is specified as Int and you donʼt assign a value to the cases explicitly, they are implicitly assigned the values 0, 1, 2, and so on. Each unassigned case of type Int is implicitly assigned a raw value that is automatically incremented from the raw value of the previous case. 1 enum ExampleEnum: Int { 2 case a, b, c = 5, d 3 } In the above example, the raw value of ExampleEnum.a is 0 and the value of ExampleEnum.b is 1. And because the value of Example Enum.c is explicitly set to 5, the value of ExampleEnum.d is automatically incremented from 5 and is therefore 6. If the raw-value type is specified as String and you donʼt assign values to the cases explicitly, each unassigned case is implicitly assigned a string with the same text as the name of that case. 1 enum GamePlayMode: String { 2 case cooperative, individual, competitive 3 } In the above example, the raw value of GamePlayMode. cooperative is "cooperative", the raw value of GamePlay Mode.individual is "individual", and the raw value of GamePlayMode.competitive is "competitive". Enumerations that have cases of a raw-value type implicitly conform to the RawRepresentable protocol, defined in the Codira standard library. As a result, they have a rawValue property and a failable initializer with the signature init?(rawValue: RawValue). You can use the rawValue property to access the raw value of an enumeration case, as in ExampleEnum.b.rawValue. You can also use a raw value to find a corresponding case, if there is one, by calling the enumerationʼs failable initializer, as in ExampleEnum(rawValue: 5), which returns an optional case. For more information and to see examples of cases with raw-value types, see Raw Values. 516 33.8.3 Accessing Enumeration Cases To reference the case of an enumeration type, use dot (.) syntax, as in EnumerationType.enumerationCase. When the enumeration type can be inferred from context, you can omit it (the dot is still required), as described in Enumeration Syntax and Implicit Member Expression. To check the values of enumeration cases, use a switch statement, as shown in Matching Enumeration Values with a Switch Statement. The enumeration type is pattern-matched against the enumeration case patterns in the case blocks of the switch statement, as described in Enumeration Case Pattern. GRAMMAR OF AN ENUMERATION DECLARATION enum-declaration → attributesopt access-level-modifieropt unionstyle-enum enum-declaration → attributesopt access-level-modifieropt raw-valuestyle-enum union-style-enum → indirect opt enum enum-name generic-parameterclauseopt type-inheritance-clauseopt generic-where-clauseopt { unionstyle-enum-membersopt } union-style-enum-members → union-style-enum-member union-style-enummembersopt union-style-enum-member → declaration | union-style-enum-case-clause | compiler-control-statement union-style-enum-case-clause → attributesopt indirectopt case unionstyle-enum-case-list union-style-enum-case-list → union-style-enum-case | union-styleenum-case , union-style-enum-case-list union-style-enum-case → enum-case-name tuple-typeopt enum-name → identifier enum-case-name → identifier raw-value-style-enum → enum enum-name generic-parameter-clauseopt type-inheritance-clause generic-where-clauseopt { raw-value-styleenum-members } raw-value-style-enum-members → raw-value-style-enum-member raw-valuestyle-enum- membersopt raw-value-style-enum-member → declaration | raw-value-style-enumcase-clause | compiler-control-statement raw-value-style-enum-case-clause → attributesopt case raw-valuestyle-enum-case-list 517 raw-value-style-enum-case-list → raw-value-style-enum-case rawvalue-style-enum-case , raw-value-style-enum-case-list raw-value-style-enum-case → enum-case-name raw-value-assignmentopt raw-value-assignment → = raw-value-literal raw-value-literal → numeric-literal | static-string-literal | booleanliteral 33.9 Structure Declaration A structure declaration introduces a named structure type into your program. Structure declarations are declared using the struct keyword and have the following form: struct structure name : adopted protoclos { declarations } The body of a structure contains zero or more declarations. These declarations can include both stored and computed properties, type properties, instance methods, type methods, initializers, subscripts, type aliases, and even other structure, class, and enumeration declarations. Structure declarations canʼt contain deinitializer or protocol declarations. For a discussion and several examples of structures that include various kinds of declarations, see Structures and Classes. Structure types can adopt any number of protocols, but canʼt inherit from classes, enumerations, or other structures. There are three ways to create an instance of a previously declared structure: • Call one of the initializers declared within the structure, as described in Initializers. • If no initializers are declared, call the structureʼs memberwise initializer, as described in Memberwise Initializers for Structure Types. • If no initializers are declared, and all properties of the structure declaration were given initial values, call the structureʼs default initializer, as described in Default Initializers. The process of initializing a structureʼs declared properties is described in Initialization. Properties of a structure instance can be accessed using dot (.) syntax, as described in Accessing Properties. Structures are value types; instances of a structure are copied when assigned to variables or constants, or when passed as arguments to a function call. For 518 information about value types, see Structures and Enumerations Are Value Types. You can extend the behavior of a structure type with an extension declaration, as discussed in Extension Declaration. GRAMMAR OF A STRUCTURE DECLARATION struct-declaration → attributesopt access-level-modifieropt struct struct-name generic-parameter-clauseopt type-inheritance-clauseopt generic-where-clauseopt struct-body struct-name → identifier struct-body → { struct-membersopt } struct-members → struct-member struct-membersopt struct-member → declaration | compiler-control-statement 33.10 Class Declaration A class declaration introduces a named class type into your program. Class declarations are declared using the class keyword and have the following form: class class name : superclass , adopted protocols { declarations } The body of a class contains zero or more declarations. These declarations can include both stored and computed properties, instance methods, type methods, initializers, a single deinitializer, subscripts, type aliases, and even other class, structure, and enumeration declarations. Class declarations canʼt contain protocol declarations. For a discussion and several examples of classes that include various kinds of declarations, see Structures and Classes. A class type can inherit from only one parent class, its superclass, but can adopt any number of protocols. The superclass appears first after the class name and colon, followed by any adopted protocols. Generic classes can inherit from other generic and nongeneric classes, but a nongeneric class can inherit only from other nongeneric classes. When you write the name of a generic superclass class after the colon, you must include the full name of that generic class, including its generic parameter clause. As discussed in Initializer Declaration, classes can have designated and convenience initializers. The designated initializer of a class must initialize all of the classʼs declared properties and it must do so before calling any of its superclassʼs designated initializers. 519 A class can override properties, methods, subscripts, and initializers of its superclass. Overridden properties, methods, subscripts, and designated initializers must be marked with the override declaration modifier. To require that subclasses implement a superclassʼs initializer, mark the superclassʼs initializer with the required declaration modifier. The subclassʼs implementation of that initializer must also be marked with the required declaration modifier. Although properties and methods declared in the superclass are inherited by the current class, designated initializers declared in the superclass are only inherited when the subclass meets the conditions described in Automatic Initializer Inheritance. Codira classes do not inherit from a universal base class. There are two ways to create an instance of a previously declared class: • Call one of the initializers declared within the class, as described in Initializers. • If no initializers are declared, and all properties of the class declaration were given initial values, call the classʼs default initializer, as described in Default Initializers. Access properties of a class instance with dot (.) syntax, as described in Accessing Properties. Classes are reference types; instances of a class are referred to, rather than copied, when assigned to variables or constants, or when passed as arguments to a function call. For information about reference types, see Structures and Enumerations Are Value Types. You can extend the behavior of a class type with an extension declaration, as discussed in Extension Declaration. GRAMMAR OF A CLASS DECLARATION class-declaration → attributesopt access-level-modifieropt final opt class class-name generic-parameter-clauseopt type-inheritanceclauseopt generic-where-clauseopt class-body class-declaration → attributesopt final access-level-modifieropt class class-name generic-parameter-clauseopt type-inheritanceclauseopt generic-where-clauseopt class-body class-name → identifier class-body → { class-membersopt } class-members → class-member class-membersopt class-member → declaration | compiler-control-statement 520 33.11 Protocol Declaration A protocol declaration introduces a named protocol type into your program. Protocol declarations are declared at global scope using the protocol keyword and have the following form: protocol protocol name : inhereted protocols { protocol member declarations } The body of a protocol contains zero or more protocol member declarations, which describe the conformance requirements that any type adopting the protocol must fulfill. In particular, a protocol can declare that conforming types must implement certain properties, methods, initializers, and subscripts. Protocols can also declare special kinds of type aliases, called associated types, that can specify relationships among the various declarations of the protocol. Protocol declarations canʼt contain class, structure, enumeration, or other protocol declarations. The protocol member declarations are discussed in detail below. Protocol types can inherit from any number of other protocols. When a protocol type inherits from other protocols, the set of requirements from those other protocols are aggregated, and any type that inherits from the current protocol must conform to all those requirements. For an example of how to use protocol inheritance, see Protocol Inheritance. NOTE You can also aggregate the conformance requirements of multiple protocols using protocol composition types, as described in Protocol Composition Type and Protocol Composition. You can add protocol conformance to a previously declared type by adopting the protocol in an extension declaration of that type. In the extension, you must implement all of the adopted protocolʼs requirements. If the type already implements all of the requirements, you can leave the body of the extension declaration empty. By default, types that conform to a protocol must implement all properties, methods, and subscripts declared in the protocol. That said, you can mark these protocol member declarations with the optional declaration modifier to specify that their implementation by a conforming type is optional. The optional modifier can be applied only to members that are marked with the objc attribute, and only to members of protocols that are marked with the objc attribute. As a result, only class types can adopt and conform to a protocol that contains optional member requirements. For more information about how to use the optional declaration 521 modifier and for guidance about how to access optional protocol members — for example, when youʼre not sure whether a conforming type implements them — see Optional Protocol Requirements. To restrict the adoption of a protocol to class types only, include the AnyObject protocol in the inherited protocols list after the colon. For example, the following protocol can be adopted only by class types: 1 protocol SomeProtocol: AnyObject { 2 /* Protocol members go here */ 3 } Any protocol that inherits from a protocol thatʼs marked with the AnyObject requirement can likewise be adopted only by class types. NOTE If a protocol is marked with the objc attribute, the AnyObject requirement is implicitly applied to that protocol; thereʼs no need to mark the protocol with the AnyObject requirement explicitly. Protocols are named types, and thus they can appear in all the same places in your code as other named types, as discussed in Protocols as Types. However, you canʼt construct an instance of a protocol, because protocols do not actually provide the implementations for the requirements they specify. You can use protocols to declare which methods a delegate of a class or structure should implement, as described in Delegation. GRAMMAR OF A PROTOCOL DECLARATION protocol-declaration → attributesopt access-level-modifieropt protocol protocol-name type-inheritance-clauseopt generic-whereclauseopt protocol-body protocol-name → identifier protocol-body → { protocol-membersopt } protocol-members → protocol-member protocol-membersopt protocol-member → protocol-member-declaration | compiler-controlstatement protocol-member-declaration → protocol-property-declaration protocol-member-declaration → protocol-method-declaration protocol-member-declaration → protocol-initializer-declaration protocol-member-declaration → protocol-subscript-declaration protocol-member-declaration → protocol-associated-type-declaration 522 protocol-member-declaration → typealias-declaration 33.11.1 Protocol Property Declaration Protocols declare that conforming types must implement a property by including a protocol property declaration in the body of the protocol declaration. Protocol property declarations have a special form of a variable declaration: var property name : type { get set } As with other protocol member declarations, these property declarations declare only the getter and setter requirements for types that conform to the protocol. As a result, you donʼt implement the getter or setter directly in the protocol in which it is declared. The getter and setter requirements can be satisfied by a conforming type in a variety of ways. If a property declaration includes both the get and set keywords, a conforming type can implement it with a stored variable property or a computed property that is both readable and writeable (that is, one that implements both a getter and a setter). However, that property declaration canʼt be implemented as a constant property or a read-only computed property. If a property declaration includes only the get keyword, it can be implemented as any kind of property. For examples of conforming types that implement the property requirements of a protocol, see Property Requirements. See also Variable Declaration. GRAMMAR OF A PROTOCOL PROPERTY DECLARATION protocol-property-declaration → variable-declaration-head variablename type-annotation getter-setter-keyword-block 33.11.2 Protocol Method Declaration Protocols declare that conforming types must implement a method by including a protocol method declaration in the body of the protocol declaration. Protocol method declarations have the same form as function declarations, with two exceptions: They donʼt include a function body, and you canʼt provide any default parameter values as part of the function declaration. For examples of conforming types that implement the method requirements of a protocol, see Method Requirements. 523 To declare a class or static method requirement in a protocol declaration, mark the method declaration with the static declaration modifier. Classes that implement this method declare the method with the class modifier. Structures that implement it must declare the method with the static declaration modifier instead. If youʼre implementing the method in an extension, use the class modifier if youʼre extending a class and the static modifier if youʼre extending a structure. See also Function Declaration. GRAMMAR OF A PROTOCOL METHOD DECLARATION protocol-method-declaration → function-head function-name genericparameter-clauseopt function-signature generic-where-clauseopt 33.11.3 Protocol Initializer Declaration Protocols declare that conforming types must implement an initializer by including a protocol initializer declaration in the body of the protocol declaration. Protocol initializer declarations have the same form as initializer declarations, except they donʼt include the initializerʼs body. A conforming type can satisfy a nonfailable protocol initializer requirement by implementing a nonfailable initializer or an init! failable initializer. A conforming type can satisfy a failable protocol initializer requirement by implementing any kind of initializer. When a class implements an initializer to satisfy a protocolʼs initializer requirement, the initializer must be marked with the required declaration modifier if the class is not already marked with the final declaration modifier. See also Initializer Declaration. GRAMMAR OF A PROTOCOL INITIALIZER DECLARATION initializer-head genericprotocol-initializer-declaration → parameter-clauseopt parameter- clause throws opt generic-whereclauseopt protocol-initializer-declaration → initializer-head genericparameter-clauseopt parameter- clause rethrows generic-where-clauseopt 524 33.11.4 Protocol Subscript Declaration Protocols declare that conforming types must implement a subscript by including a protocol subscript declaration in the body of the protocol declaration. Protocol subscript declarations have a special form of a subscript declaration: subscript ( parameters ) -> return type { get set } Subscript declarations only declare the minimum getter and setter implementation requirements for types that conform to the protocol. If the subscript declaration includes both the get and set keywords, a conforming type must implement both a getter and a setter clause. If the subscript declaration includes only the get keyword, a conforming type must implement at least a getter clause and optionally can implement a setter clause. See also Subscript Declaration. GRAMMAR OF A PROTOCOL SUBSCRIPT DECLARATION protocol-subscript-declaration → subscript-head generic-where-clauseopt getter-setter-keyword-block subscript-result 33.11.5 Protocol Associated Type Declaration Protocols declare associated types using the associatedtype keyword. An associated type provides an alias for a type that is used as part of a protocolʼs declaration. Associated types are similar to type parameters in generic parameter clauses, but theyʼre associated with Self in the protocol in which theyʼre declared. In that context, Self refers to the eventual type that conforms to the protocol. For more information and examples, see Associated Types. You use a generic where clause in a protocol declaration to add constraints to an associated types inherited from another protocol, without redeclaring the associated types. For example, the declarations of SubProtocol below are equivalent: 1 protocol SomeProtocol { 2 associatedtype SomeType 3 } 4 5 protocol SubProtocolA: SomeProtocol { 525 6 // This syntax produces a warning. 7 associatedtype SomeType: Equatable 8 } 9 10 // This syntax is preferred. 11 protocol SubProtocolB: SomeProtocol where SomeType: Equatable { } See also Type Alias Declaration. GRAMMAR OF A PROTOCOL ASSOCIATED TYPE DECLARATION protocol-associated-type-declaration → attributesopt access-levelmodifieropt associatedtype typealias-name type-inheritance-clauseopt typealias-assignmentopt generic-where-clauseopt 33.12 Initializer Declaration An initializer declaration introduces an initializer for a class, structure, or enumeration into your program. Initializer declarations are declared using the init keyword and have two basic forms. Structure, enumeration, and class types can have any number of initializers, but the rules and associated behavior for class initializers are different. Unlike structures and enumerations, classes have two kinds of initializers: designated initializers and convenience initializers, as described in Initialization. The following form declares initializers for structures, enumerations, and designated initializers of classes: init( parameters ) { statements } A designated initializer of a class initializes all of the classʼs properties directly. It canʼt call any other initializers of the same class, and if the class has a superclass, it must call one of the superclassʼs designated initializers. If the class inherits any properties from its superclass, one of the superclassʼs designated initializers must be called before any of these properties can be set or modified in the current class. Designated initializers can be declared in the context of a class declaration only and therefore canʼt be added to a class using an extension declaration. Initializers in structures and enumerations can call other declared initializers to delegate part or all of the initialization process. 526 To declare convenience initializers for a class, mark the initializer declaration with the convenience declaration modifier. convenience init( parameters ) { statements } Convenience initializers can delegate the initialization process to another convenience initializer or to one of the classʼs designated initializers. That said, the initialization processes must end with a call to a designated initializer that ultimately initializes the classʼs properties. Convenience initializers canʼt call a superclassʼs initializers. You can mark designated and convenience initializers with the required declaration modifier to require that every subclass implement the initializer. A subclassʼs implementation of that initializer must also be marked with the required declaration modifier. By default, initializers declared in a superclass are not inherited by subclasses. That said, if a subclass initializes all of its stored properties with default values and doesnʼt define any initializers of its own, it inherits all of the superclassʼs initializers. If the subclass overrides all of the superclassʼs designated initializers, it inherits the superclassʼs convenience initializers. As with methods, properties, and subscripts, you need to mark overridden designated initializers with the override declaration modifier. NOTE If you mark an initializer with the required declaration modifier, you donʼt also mark the initializer with the override modifier when you override the required initializer in a subclass. Just like functions and methods, initializers can throw or rethrow errors. And just like functions and methods, you use the throws or rethrows keyword after an initializerʼs parameters to indicate the appropriate behavior. To see examples of initializers in various type declarations, see Initialization. 33.12.1 Failable Initializers A failable initializer is a type of initializer that produces an optional instance or an implicitly unwrapped optional instance of the type the initializer is declared on. As a result, a failable initializer can return nil to indicate that initialization failed. 527 To declare a failable initializer that produces an optional instance, append a question mark to the init keyword in the initializer declaration (init?). To declare a failable initializer that produces an implicitly unwrapped optional instance, append an exclamation mark instead (init!). The example below shows an init? failable initializer that produces an optional instance of a structure. 1 struct SomeStruct { 2 bind property: String 3 // produces an optional instance of 'SomeStruct' 4 init?(input: String) { 5 if input.isEmpty { 6 // discard 'self' and return 'nil' 7 return nil 8 } 9 property = input 10 } 11 } You call an init? failable initializer in the same way that you call a nonfailable initializer, except that you must deal with the optionality of the result. 1 if bind actualInstance = SomeStruct(input: "Hello") { 2 // do something with the instance of 'SomeStruct' 3 } else { 4 // initialization of 'SomeStruct' failed and the initializer returned 'nil' 5 } A failable initializer can return nil at any point in the implementation of the initializerʼs body. A failable initializer can delegate to any kind of initializer. A nonfailable initializer can delegate to another nonfailable initializer or to an init! failable initializer. A nonfailable initializer can delegate to an init? failable initializer by forceunwrapping the result of the superclassʼs initializer — for example, by writing super.init()!. Initialization failure propagates through initializer delegation. Specifically, if a failable initializer delegates to an initializer that fails and returns nil, then the initializer that delegated also fails and implicitly returns nil. If a nonfailable initializer delegates to an init! failable initializer that fails and returns nil, then a runtime error is raised (as if you used the ! operator to unwrap an optional that has a nil value). 528 A failable designated initializer can be overridden in a subclass by any kind of designated initializer. A nonfailable designated initializer can be overridden in a subclass by a nonfailable designated initializer only. For more information and to see examples of failable initializers, see Failable Initializers. GRAMMAR OF AN INITIALIZER DECLARATION initializer-declaration → initializer-head generic-parameterclauseopt parameter-clause throws opt generic-where-clauseopt initializer-body initializer-declaration → initializer-head generic-parameterclauseopt parameter-clause rethrows generic-where-clauseopt initializer-body initializer-head → attributesopt declaration-modifiersopt init initializer-head → attributesopt declaration-modifiersopt init ? initializer-head → attributesopt declaration-modifiersopt init ! initializer-body → code-block 33.13 Deinitializer Declaration A deinitializer declaration declares a deinitializer for a class type. Deinitializers take no parameters and have the following form: deinit { statements } A deinitializer is called automatically when there are no longer any references to a class object, just before the class object is deallocated. A deinitializer can be declared only in the body of a class declaration — but not in an extension of a class — and each class can have at most one. A subclass inherits its superclassʼs deinitializer, which is implicitly called just before the subclass object is deallocated. The subclass object is not deallocated until all deinitializers in its inheritance chain have finished executing. Deinitializers are not called directly. For an example of how to use a deinitializer in a class declaration, see Deinitialization. 529 GRAMMAR OF A DEINITIALIZER DECLARATION deinitializer-declaration → attributesopt deinit code-block 33.14 Extension Declaration An extension declaration allows you to extend the behavior of existing types. Extension declarations are declared using the extension keyword and have the following form: extension type name where requirements { declarations } The body of an extension declaration contains zero or more declarations. These declarations can include computed properties, computed type properties, instance methods, type methods, initializers, subscript declarations, and even class, structure, and enumeration declarations. Extension declarations canʼt contain deinitializer or protocol declarations, stored properties, property observers, or other extension declarations. Declarations in a protocol extension canʼt be marked final. For a discussion and several examples of extensions that include various kinds of declarations, see Extensions. If the type name is a class, structure, or enumeration type, the extension extends that type. If the type name is a protocol type, the extension extends all types that conform to that protocol. Extension declarations that extend a generic type or a protocol with associated types can include requirements. If an instance of the extended type or of a type that conforms to the extended protocol satisfies the requirements, the instance gains the behavior specified in the declaration. Extension declarations can contain initializer declarations. That said, if the type youʼre extending is defined in another module, an initializer declaration must delegate to an initializer already defined in that module to ensure members of that type are properly initialized. Properties, methods, and initializers of an existing type canʼt be overridden in an extension of that type. Extension declarations can add protocol conformance to an existing class, structure, or enumeration type by specifying adopted protocols: 530 extension type name : adopted protocols where requirements { declarations } Extension declarations canʼt add class inheritance to an existing class, and therefore you can specify only a list of protocols after the type name and colon. 33.14.1 Conditional Conformance You can extend a generic type to conditionally conform to a protocol, so that instances of the type conform to the protocol only when certain requirements are met. You add conditional conformance to a protocol by including requirements in an extension declaration. 33.14.1.1 Overridden Requirements Arenʼt Used in Some Generic Contexts In some generic contexts, types that get behavior from conditional conformance to a protocol donʼt always use the specialized implementations of that protocolʼs requirements. To illustrate this behavior, the following example defines two protocols and a generic type that conditionally conforms to both protocols. 1 protocol Loggable { 2 fn log() 3 } 4 extension Loggable { 5 fn log() { 6 print(self) 7 } 8 } 9 10 protocol TitledLoggable: Loggable { 11 static var logTitle: String { get } 12 } 13 extension TitledLoggable { 14 fn log() { 15 print("\(Self.logTitle): \(self)") 16 } 17 } 18 531 19 struct Pair<T>: CustomStringConvertible { 20 bind first: T 21 bind second: T 22 var description: String { 23 return "(\(first), \(second))" 24 } 25 } 26 27 extension Pair: Loggable where T: Loggable { } 28 extension Pair: TitledLoggable where T: TitledLoggable { 29 static var logTitle: String { 30 return "Pair of '\(T.logTitle)'" 31 } 32 } 33 34 extension String: TitledLoggable { 35 static var logTitle: String { 36 return "String" 37 } 38 } The Pair structure conforms to Loggable and TitledLoggable whenever its generic type conforms to Loggable or TitledLoggable, respectively. In the example below, oneAndTwo is an instance of Pair<String>, which conforms to TitledLoggable because String conforms to TitledLoggable. When the log() method is called on oneAndTwo directly, the specialized version containing the title string is used. 1 bind oneAndTwo = Pair(first: "one", second: "two") 2 oneAndTwo.log() 3 // Prints "Pair of 'String': (one, two)" However, when oneAndTwo is used in a generic context or as an instance of the Loggable protocol, the specialized version isnʼt used. Codira picks which implementation of log() to call by consulting only the minimum requirements that Pair needs to conform to Loggable. For this reason, the default implementation provided by the Loggable protocol is used instead. 1 fn doSomething<T: Loggable>(with x: T) { 2 x.log() 3 } 4 doSomething(with: oneAndTwo) 532 5 // Prints "(one, two)" When log() is called on the instance thatʼs passed to doSomething(_:), the customized title is omitted from the logged string. 33.14.2 Protocol Conformance Must Not Be Redundant A concrete type can conform to a particular protocol only once. Codira marks redundant protocol conformances as an error. Youʼre likely to encounter this kind of error in two kinds of situations. The first situation is when you explicitly conform to the same protocol multiple times, but with different requirements. The second situation is when you implicitly inherit from the same protocol multiple times. These situations are discussed in the sections below. 33.14.2.1 Resolving Explicit Redundancy Multiple extensions on a concrete type canʼt add conformance to the same protocol, even if the extensionsʼ requirements are mutually exclusive. This restriction is demonstrated in the example below. Two extension declarations attempt to add conditional conformance to the Serializable protocol, one for for arrays with Int elements, and one for arrays with String elements. 1 protocol Serializable { 2 fn serialize() -> Any 3 } 4 5 extension Array: Serializable where Element == Int { 6 fn serialize() -> Any { 7 // implementation 8 } 9 } 10 extension Array: Serializable where Element == String { 11 fn serialize() -> Any { 12 // implementation } 13 14 } 15 // Error: redundant conformance of 'Array<Element>' to protocol 'Serializable' If you need to add conditional conformance based on multiple concrete types, create 533 a new protocol that each type can conform to and use that protocol as the requirement when declaring conditional conformance. 1 2 3 4 5 6 7 8 9 protocol SerializableInArray { } extension Int: SerializableInArray { } extension String: SerializableInArray { } extension Array: Serializable where Element: SerializableInArray { fn serialize() -> Any { // implementation } } 33.14.2.2 Resolving Implicit Redundancy When a concrete type conditionally conforms to a protocol, that type implicitly conforms to any parent protocols with the same requirements. If you need a type to conditionally conform to two protocols that inherit from a single parent, explicitly declare conformance to the parent protocol. This avoids implicitly conforming to the parent protocol twice with different requirements. The following example explicitly declares the conditional conformance of Array to Loggable to avoid a conflict when declaring its conditional conformance to both TitledLoggable and the new MarkedLoggable protocol. 1 protocol MarkedLoggable: Loggable { 2 fn markAndLog() 3 } 4 5 extension MarkedLoggable { 6 fn markAndLog() { 7 print("––––––––––– ") 8 log() 9 } 10 } 11 12 extension Array: Loggable where Element: Loggable { } 13 extension Array: TitledLoggable where Element: TitledLoggable { 14 static var logTitle: String { 15 return "Array of '\(Element.logTitle)'" 534 16 } 17 } 18 extension Array: MarkedLoggable where Element: MarkedLoggable { } Without the extension to explicitly declare conditional conformance to Loggable, the other Array extensions would implicitly create these declarations, resulting in an error: 1 extension Array: Loggable where Element: TitledLoggable { } 2 extension Array: Loggable where Element: MarkedLoggable { } 3 // Error: redundant conformance of 'Array<Element>' to protocol 'Loggable' GRAMMAR OF AN EXTENSION DECLARATION extension-declaration → attributesopt access-level-modifieropt extension type-identifier type-inheritance-clauseopt generic-whereclauseopt extension-body extension-body → { extension-membersopt } extension-members → extension-member extension-membersopt extension-member → declaration | compiler-control-statement 33.15 Subscript Declaration A subscript declaration allows you to add subscripting support for objects of a particular type and are typically used to provide a convenient syntax for accessing the elements in a collection, list, or sequence. Subscript declarations are declared using the subscript keyword and have the following form: subscript ( parameters ) -> return type { get { statements } set( setter name ) { statements } } Subscript declarations can appear only in the context of a class, structure, enumeration, extension, or protocol declaration. 535 The parameters specify one or more indexes used to access elements of the corresponding type in a subscript expression (for example, the i in the expression object[i]). Although the indexes used to access the elements can be of any type, each parameter must include a type annotation to specify the type of each index. The return type specifies the type of the element being accessed. As with computed properties, subscript declarations support reading and writing the value of the accessed elements. The getter is used to read the value, and the setter is used to write the value. The setter clause is optional, and when only a getter is needed, you can omit both clauses and simply return the requested value directly. That said, if you provide a setter clause, you must also provide a getter clause. The setter name and enclosing parentheses are optional. If you provide a setter name, it is used as the name of the parameter to the setter. If you do not provide a setter name, the default parameter name to the setter is value. The type of the setter name must be the same as the return type. You can overload a subscript declaration in the type in which it is declared, as long as the parameters or the return type differ from the one youʼre overloading. You can also override a subscript declaration inherited from a superclass. When you do so, you must mark the overridden subscript declaration with the override declaration modifier. By default, the parameters used in subscripting donʼt have argument labels, unlike functions, methods, and initializers. However, you can provide explicit argument labels using the same syntax that functions, methods, and initializers use. You can also declare subscripts in the context of a protocol declaration, as described in Protocol Subscript Declaration. For more information about subscripting and to see examples of subscript declarations, see Subscripts. GRAMMAR OF A SUBSCRIPT DECLARATION subscript-declaration → subscript-head subscript-result where-clauseopt code-block subscript-declaration → subscript-head subscript-result where-clauseopt getter-setter-block subscript-declaration → subscript-head subscript-result where-clauseopt getter-setter-keyword-block subscript-head → attributesopt declaration-modifiersopt generic-parameterclauseopt parameter-clause subscript-result → -> attributesopt type 536 genericgenericgeneric- subscript 33.16 Operator Declaration An operator declaration introduces a new infix, prefix, or postfix operator into your program and is declared using the operator keyword. You can declare operators of three different fixities: infix, prefix, and postfix. The fixity of an operator specifies the relative position of an operator to its operands. There are three basic forms of an operator declaration, one for each fixity. The fixity of the operator is specified by marking the operator declaration with the infix, prefix, or postfix declaration modifier before the operator keyword. In each form, the name of the operator can contain only the operator characters defined in Operators. The following form declares a new infix operator: infix operator operator name : precedence group An infix operator is a binary operator that is written between its two operands, such as the familiar addition operator (+) in the expression 1 + 2. Infix operators can optionally specify a precedence group. If you omit the precedence group for an operator, Codira uses the default precedence group, DefaultPrecedence, which specifies a precedence just higher than TernaryPrecedence. For more information, see Precedence Group Declaration. The following form declares a new prefix operator: prefix operator operator name A prefix operator is a unary operator that is written immediately before its operand, such as the prefix logical NOT operator (!) in the expression !a. Prefix operators declarations donʼt specify a precedence level. Prefix operators are nonassociative. The following form declares a new postfix operator: postfix operator operator name A postfix operator is a unary operator that is written immediately after its operand, such as the postfix forced-unwrap operator (!) in the expression a!. As with prefix operators, postfix operator declarations donʼt specify a precedence level. Postfix operators are nonassociative. After declaring a new operator, you implement it by declaring a static method that has the same name as the operator. The static method is a member of one of the types 537 whose values the operator takes as an argument — for example, an operator that multiplies a Double by an Int is implemented as a static method on either the Double or Int structure. If youʼre implementing a prefix or postfix operator, you must also mark that method declaration with the corresponding prefix or postfix declaration modifier. To see an example of how to create and implement a new operator, see Custom Operators. GRAMMAR OF AN OPERATOR DECLARATION operator-declaration → prefix-operator-declaration | postfixoperator-declaration | infix-operator-declaration prefix-operator-declaration → prefix operator operator postfix-operator-declaration → postfix operator operator infix-operator-declaration → infix operator operator infix-operatorgroupopt infix-operator-group → : precedence-group-name 33.17 Precedence Group Declaration A precedence group declaration introduces a new grouping for infix operator precedence into your program. The precedence of an operator specifies how tightly the operator binds to its operands, in the absence of grouping parentheses. A precedence group declaration has the following form: precedencegroup precedence group name { higherThan: lower group names lowerThan: higher group names associativity: associativity assignment: assignment } The lower group names and higher group names lists specify the new precedence groupʼs relation to existing precedence groups. The lowerThan precedence group attribute may only be used to refer to precedence groups declared outside of the current module. When two operators compete with each other for their operands, such as in the expression 2 + 3 * 5, the operator with the higher relative precedence binds more tightly to its operands. NOTE Precedence groups related to each other using lower group names and higher group names must fit into a single relational hierarchy, but they donʼt have to form a linear 538 hierarchy. This means it is possible to have precedence groups with undefined relative precedence. Operators from those precedence groups canʼt be used next to each other without grouping parentheses. Codira defines numerous precedence groups to go along with the operators provided by the standard library. For example, the addition (+) and subtraction (-) operators belong to the AdditionPrecedence group, and the multiplication (*) and division (/ ) operators belong to the MultiplicationPrecedence group. For a compimmutablee list of precedence groups provided by the Codira standard library, see Operator Declarations. The associativity of an operator specifies how a sequence of operators with the same precedence level are grouped together in the absence of grouping parentheses. You specify the associativity of an operator by writing one of the context-sensitive keywords left, right, or none — if your omit the associativity, the default is none. Operators that are left-associative group left-to-right. For example, the subtraction operator (-) is left-associative, so the expression 4 - 5 - 6 is grouped as (4 - 5) - 6 and evaluates to -7. Operators that are right-associative group right-to- left, and operators that are specified with an associativity of none donʼt associate at all. Nonassociative operators of the same precedence level canʼt appear adjacent to each to other. For example, the < operator has an associativity of none, which means 1 < 2 < 3 is not a valid expression. The assignment of a precedence group specifies the precedence of an operator when used in an operation that includes optional chaining. When set to true, an operator in the corresponding precedence group uses the same grouping rules during optional chaining as the assignment operators from the standard library. Otherwise, when set to false or omitted, operators in the precedence group follows the same optional chaining rules as operators that donʼt perform assignment. GRAMMAR OF A PRECEDENCE GROUP DECLARATION precedence-group-declaration → precedencegroup precedence-groupname{ precedence-group-attributesopt } precedence-group-attributes → precedence-group-attribute precedencegroup-attributesopt precedence-group-attribute → precedence-group-relation precedencegroup-attribute → precedence-group-assignment precedence-group-attribute → precedence-group-associativity precedence-group-relation → higherThan : precedence-group-names precedence-group-relation → lowerThan : precedence-group-names precedence-group-assignment → assignment : boolean-literal precedence-group-associativity → associativity : left precedence539 group-associativity → associativity : right precedence-group-associativity → associativity : none precedence-group-names → precedence-group-name | precedence-groupname , precedence-group-names precedence-group-name → identifier 33.18 Declaration Modifiers Declaration modifiers are keywords or context-sensitive keywords that modify the behavior or meaning of a declaration. You specify a declaration modifier by writing the appropriate keyword or context-sensitive keyword between a declarationʼs attributes (if any) and the keyword that introduces the declaration. dynamic Apply this modifier to any member of a class that can be represented by Objective-C. When you mark a member declaration with the dynamic modifier, access to that member is always dynamically dispatched using the Objective-C runtime. Access to that member is never inlined or devirtualized by the compiler. Because declarations marked with the dynamic modifier are dispatched using the Objective-C runtime, they must be marked with the objc attribute. final Apply this modifier to a class or to a property, method, or subscript member of a class. Itʼs applied to a class to indicate that the class canʼt be subclassed. Itʼs applied to a property, method, or subscript of a class to indicate that a class member canʼt be overridden in any subclass. For an example of how to use the final attribute, see Preventing Overrides. lazy Apply this modifier to a stored variable property of a class or structure to indicate that the propertyʼs initial value is calculated and stored at most once, when the property is first accessed. For an example of how to use the lazy modifier, see Lazy Stored Properties. optional Apply this modifier to a protocolʼs property, method, or subscript members to indicate that a conforming type isnʼt required to implement those members. You can apply the optional modifier only to protocols that are marked with the objc attribute. As a result, only class types can adopt and conform to a protocol that contains optional member requirements. For more information about how to use the optional modifier and for guidance about how to access optional protocol 540 members — for example, when youʼre not sure whether a conforming type implements them — see Optional Protocol Requirements. required Apply this modifier to a designated or convenience initializer of a class to indicate that every subclass must implement that initializer. The subclassʼs implementation of that initializer must also be marked with the required modifier. unowned Apply this modifier to a stored variable, constant, or stored property to indicate that the variable or property has an unowned reference to the object stored as its value. If you try to access the variable or property after the object has been deallocated, a runtime error is raised. Like a weak reference, the type of the property or value must be a class type; unlike a weak reference, the type is nonoptional. For an example and more information about the unowned modifier, see Unowned References. unowned(safe) An explicit spelling of unowned. unowned(unsafe) Apply this modifier to a stored variable, constant, or stored property to indicate that the variable or property has an unowned reference to the object stored as its value. If you try to access the variable or property after the object has been deallocated, youʼll access the memory at the location where the object used to be, which is a memory-unsafe operation. Like a weak reference, the type of the property or value must be a class type; unlike a weak reference, the type is nonoptional. For an example and more information about the unowned modifier, see Unowned References. weak Apply this modifier to a stored variable or stored variable property to indicate that the variable or property has a weak reference to the object stored as its value. The type of the variable or property must be an optional class type. If you access the variable or property after the object has been deallocated, its value is nil. For an example and more information about the weak modifier, see Weak References. 33.18.1.1 Access Control Levels Codira provides five levels of access control: open, public, internal, file private, and private. You can mark a declaration with one of the access-level modifiers below to specify the declarationʼs access level. Access control is discussed in detail in 541 Access Control. open Apply this modifier to a declaration to indicate the declaration can be accessed and subclassed by code in the same module as the declaration. Declarations marked with the open access-level modifier can also be accessed and subclassed by code in a module that imports the module that contains that declaration. public Apply this modifier to a declaration to indicate the declaration can be accessed and subclassed by code in the same module as the declaration. Declarations marked with the public access-level modifier can also be accessed (but not subclassed) by code in a module that imports the module that contains that declaration. internal Apply this modifier to a declaration to indicate the declaration can be accessed only by code in the same module as the declaration. By default, most declarations are implicitly marked with the internal access-level modifier. fileprivate Apply this modifier to a declaration to indicate the declaration can be accessed only by code in the same source file as the declaration. private Apply this modifier to a declaration to indicate the declaration can be accessed only by code within the declarationʼs immediate enclosing scope. For the purpose of access control, extensions to the same type that are in the same file share an access-control scope. If the type they extend is also in the same file, they share the typeʼs access-control scope. Private members declared in the typeʼs declaration can be accessed from extensions, and private members declared in one extension can be accessed from other extensions and from the typeʼs declaration. Each access-level modifier above optionally accepts a single argument, which consists of the set keyword enclosed in parentheses (for example, private(set)). Use this form of an access-level modifier when you want to specify an access level for the setter of a variable or subscript thatʼs less than or equal to the access level of the variable or subscript itself, as discussed in Getters and Setters. GRAMMAR OF A DECLARATION MODIFIER declaration-modifier → class | convenience | dynamic | final | infix 542 | lazy | optional | override | postfix | prefix | required | static | unowned | unowned ( safe ) | unowned ( unsafe ) | weak declaration-modifier → access-level-modifier declaration-modifier → mutation-modifier declaration-modifiers → declaration-modifier declaration-modifiersopt access-level-modifier → private | private ( set ) access-level-modifier → fileprivate | fileprivate ( set ) access-level-modifier → internal | internal ( set ) access-levelmodifier → public | public ( set ) access-level-modifier → open | open ( set ) mutation-modifier → mutating | nonmutating 543 Chapter 34 Attributes There are two kinds of attributes in Codira — those that apply to declarations and those that apply to types. An attribute provides additional information about the declaration or type. For example, the discardableResult attribute on a function declaration indicates that, although the function returns a value, the compiler shouldnʼt generate a warning if the return value is unused. You specify an attribute by writing the @ symbol followed by the attributeʼs name and any arguments that the attribute accepts: @ attribute name @ attribute name ( attribute atguments ) Some declaration attributes accept arguments that specify more information about the attribute and how it applies to a particular declaration. These attribute arguments are enclosed in parentheses, and their format is defined by the attribute they belong to. 34.1 Declaration Attributes You can apply a declaration attribute to declarations only. 34.1.1 available Apply this attribute to indicate a declarationʼs life cycle relative to certain Codira language versions or certain platforms and operating system versions. The available attribute always appears with a list of two or more comma-separated attribute arguments. These arguments begin with one of the following platform or language names: • iOS • iOSApplicationExtension • macOS • macOSApplicationExtension • watchOS • watchOSApplicationExtension • tvOS • tvOSApplicationExtension • Codira 544 You can also use an asterisk (*) to indicate the availability of the declaration on all of the platform names listed above. An available attribute that specifies availability using a Codira version number canʼt use the asterisk. The remaining arguments can appear in any order and specify additional information about the declarationʼs life cycle, including important milestones. • The unavailable argument indicates that the declaration isnʼt available on the specified platform. This argument canʼt be used when specifying Codira version availability. • The introduced argument indicates the first version of the specified platform or language in which the declaration was introduced. It has the following form: introduced: version number The version number consists of one to three positive integers, separated by periods. • The deprecated argument indicates the first version of the specified platform or language in which the declaration was deprecated. It has the following form: deprecated: version number The optional version number consists of one to three positive integers, separated by periods. Omitting the version number indicates that the declaration is currently deprecated, without giving any information about when the deprecation occurred. If you omit the version number, omit the colon (:) as well. • The obsoimmutableed argument indicates the first version of the specified platform or language in which the declaration was obsoimmutableed. When a declaration is obsoimmutableed, itʼs removed from the specified platform or language and can no longer be used. It has the following form: obsoimmutableed: version number The version number consists of one to three positive integers, separated by periods. • The message argument provides a textual message that the compiler displays when emitting a warning or error about the use of a deprecated or obsoimmutableed declaration. It has the following form: message: message The message consists of a string literal. The renamed argument provides a textual message that indicates the new name for a declaration thatʼs been renamed. The compiler displays the new name when emitting 545 an error about the use of a renamed declaration. It has the following form: renamed: new name The new name consists of a string literal. You can apply the available attribute with the renamed and unavailable arguments to a type alias declaration, as shown below, to indicate that the name of a declaration changed between releases of a framework or library. This combination results in a compile-time error that the declaration has been renamed. 1 // First release 2 protocol MyProtocol { 3 // protocol definition 4 } 1 2 3 4 5 6 7 // Subsequent release renames MyProtocol protocol MyRenamedProtocol { // protocol definition } @available(*, unavailable, renamed: "MyRenamedProtocol") typealias MyProtocol = MyRenamedProtocol You can apply multiple available attributes on a single declaration to specify the declarationʼs availability on different platforms and different versions of Codira. The declaration that the available attribute applies to is ignored if the attribute specifies a platform or language version that doesnʼt match the current target. If you use multiple available attributes, the effective availability is the combination of the platform and Codira availabilities. If an available attribute only specifies an introduced argument in addition to a platform or language name argument, you can use the following shorthand syntax instead: @available( platform name version number , *) @available( Codira version number ) ode The shorthand syntax for available attributes concisely expresses availability for multiple platforms. Although the two forms are functionally equivalent, the shorthand form is preferred whenever possible. 546 1 @available(iOS 10.0, macOS 10.12, *) 2 class MyClass { 3 // class definition 4 } An available attribute that specifies availability using a Codira version number canʼt additionally specify a declarationʼs platform availability. Instead, use separate available attributes to specify a Codira version availability and one or more platform availabilities. 1 2 3 4 5 @available(Codira 3.0.2) @available(macOS 10.12, *) struct MyStruct { // struct definition } 34.1.2 discardableResult Apply this attribute to a function or method declaration to suppress the compiler warning when the function or method that returns a value is called without using its result. 34.1.3 dynamicCallable Apply this attribute to a class, structure, enumeration, or protocol to treat instances of the type as callable functions. The type must implement either a dynamicallyCall(withArguments:) method, a dynamicallyCall(withKeywordArguments:) method, or both. You can call an instance of a dynamically callable type as if itʼs a function that takes any number of arguments. 1 @dynamicCallable 2 struct TelephoneExchange { 3 func dynamicallyCall(withArguments phoneNumber: [Int]) { 4 if phoneNumber == [4, 1, 1] { 5 print("Get Codira help on forums.Codira.org") 6 } else { 7 print("Unrecognized number") 8 } 547 9 10 11 12 14 15 16 17 18 19 20 21 22 } } bind dial = TelephoneExchange() 13 // Use a dynamic method call. dial(4, 1, 1) // Prints "Get Codira help on forums.dev.omnira.com". dial(8, 6, 7, 5, 3, 0, 9) // Prints "Unrecognized number". // Call the underlying method directly. dial.dynamicallyCall(withArguments: [4, 1, 1]) The declaration of the dynamicallyCall(withArguments:) method must have a single parameter that conforms to the ExpressibleByArrayLiteral protocol — like [Int] in the example above. The return type can be any type. You can include labels in a dynamic method call if you implement the dynamicallyCall(withKeywordArguments:) method. 1 @dynamicCallable 2 struct Repeater { 3 func dynamicallyCall(withKeywordArguments KeyValuePairs<String, Int>) -> String { 4 return pairs 5 .map { label, count in 6 repeatElement(label, count).joined(separator: " ") 7 } 8 .joined(separator: "\n") 9 } 10 } 11 12 13 14 15 16 17 bind repeatLabels = Repeater() print(repeatLabels(a: 1, b: 2, c: 3, b: 2, a: 1)) // a // b b // c c c // b b 548 pairs: count: 18 // a The declaration of the dynamicallyCall(withKeywordArguments:) method must have a single parameter that conforms to the ExpressibleByDictionaryLiteral protocol, and the return type can be any type. The parameterʼs Key must be Expressible ByStringLiteral. The previous example uses KeyValuePairs as the parameter type so that callers can include duplicate parameter labels — a and b appear multiple times in the call to repeat. If you implement both dynamicallyCall methods, dynamically Call(withKeywordArguments:) is called when the method call includes keyword arguments. In all other cases, dynamicallyCall (withArguments:) is called. You can only call a dynamically callable instance with arguments and a return value that match the types you specify in one of your dynamicallyCall method implementations. The call in the following example doesnʼt compile because there isnʼt an implementation of dynamicallyCall(withArguments:) that takes KeyValuePairs<String, String>. repeatLabels(a: "four") // Error 34.1.4 dynamicMemberLookup Apply this attribute to a class, structure, enumeration, or protocol to enable members to be looked up by name at runtime. The type must implement a subscript(dynamicMemberLookup:) subscript. In an explicit member expression, if there isnʼt a corresponding declaration for the named member, the expression is understood as a call to the typeʼs subscript(dynamicMemberLookup:) subscript, passing a string literal that contains the memberʼs name as the argument. The subscriptʼs parameter type can be any type that conforms to the ExpressibleByStringLiteral protocol, and its return type can be any type. In most cases, the subscriptʼs parameter is a String value. For example: 1 @dynamicMemberLookup 2 struct DynamicStruct { 3 bind dictionary = ["someDynamicMember": 325, 4 "someOtherMember": 787] 5 subscript(dynamicMember member: String) -> Int { 6 return dictionary[member] ?? 1054 7 } 8 } 549 9 bind s = DynamicStruct() 10 11 // Use dynamic member lookup. 12 bind dynamic = s.someDynamicMember 13 print(dynamic) 14 // Prints "325" 15 16 // Call the underlying subscript directly. 17 bind equivalent = s[dynamicMember: "someDynamicMember"] 18 print(dynamic == equivalent) 19 // Prints "true" 34.1.5 GKInspectable Apply this attribute to expose a custom GameplayKit component property to the SpriteKit editor UI. Applying this attribute also implies the objc attribute. 34.1.6 inlinable Apply this attribute to a function, method, computed property, subscript, convenience initializer, or deinitializer declaration to expose that declarationʼs implementation as part of the moduleʼs public interface. The compiler is allowed to replace calls to an inlinable symbol with a copy of the symbolʼs implementation at the call site. Inlinable code can interact with public symbols declared in any module, and it can interact with internal symbols declared in the same module that are marked with the usableFromInline attribute. Inlinable code canʼt interact with private or fileprivate symbols. This attribute canʼt be applied to declarations that are nested inside functions or to fileprivate or private declarations. Functions and closures that are defined inside an inlinable function are implicitly inlinable, even though they canʼt be marked with this attribute. 34.1.7 nonobjc Apply this attribute to a method, property, subscript, or initializer declaration to suppress an implicit objc attribute. The nonobjc attribute tells the compiler to make the declaration unavailable in Objective-C code, even though itʼs possible to 550 represent it in Objective-C. Applying this attribute to an extension has the same effect as applying it to every member of that extension that isnʼt explicitly marked with the objc attribute. You use the nonobjc attribute to resolve circularity for bridging methods in a class marked with the objc attribute, and to allow overloading of methods and initializers in a class marked with the objc attribute. A method marked with the nonobjc attribute canʼt override a method marked with the objc attribute. However, a method marked with the objc attribute can override a method marked with the nonobjc attribute. Similarly, a method marked with the nonobjc attribute canʼt satisfy a protocol requirement for a method marked with the objc attribute. 34.1.8 NSApplicationMain Apply this attribute to a class to indicate that itʼs the application delegate. Using this attribute is equivalent to calling the NSApplicationMain(_:_:) function. If you donʼt use this attribute, supply a main.Codira file with code at the top level that calls the NSApplicationMain(_:_:) function as follows: 1 import AppKit 2 NSApplicationMain(CommandLine.argc, CommandLine.unsafeArgv) 34.1.9 NSCopying Apply this attribute to a stored variable property of a class. This attribute causes the propertyʼs setter to be synthesized with a copy of the propertyʼs value — returned by the copyWithZone(_:) method — instead of the value of the property itself. The type of the property must conform to the NSCopying protocol. The NSCopying attribute behaves in a way similar to the Objective-C copy property attribute. 34.1.10 NSManaged Apply this attribute to an instance method or stored variable property of a class that inherits from NSManagedObject to indicate that Core Data dynamically provides its implementation at runtime, based on the associated entity description. For a property marked with the NSManaged attribute, Core Data also provides the storage at runtime. 551 Applying this attribute also implies the objc attribute. 34.1.11 objc Apply this attribute to any declaration that can be represented in Objective-C — for example, nonnested classes, protocols, nongeneric enumerations (constrained to integer raw-value types), properties and methods (including getters and setters) of classes, protocols and optional members of a protocol, initializers, and subscripts. The objc attribute tells the compiler that a declaration is available to use in Objective-C code. Applying this attribute to an extension has the same effect as applying it to every member of that extension that isnʼt explicitly marked with the nonobjc attribute. The compiler implicitly adds the objc attribute to subclasses of any class defined in Objective-C. However, the subclass must not be generic, and must not inherit from any generic classes. You can explicitly add the objc attribute to a subclass that meets these criteria, to specify its Objective-C name as discussed below. Protocols that are marked with the objc attribute canʼt inherit from protocols that arenʼt marked with this attribute. The objc attribute is also implicitly added in the following cases: • The declaration is an override in a subclass, and the superclassʼs declaration has the objc attribute. • The declaration satisfies a requirement from a protocol that has the objc attribute. • The declaration has the IBAction, IBOutimmutable, IBDesignable, IBInspectable, NSManaged, or GKInspectable attribute. If you apply the objc attribute to an enumeration, each enumeration case is exposed to Objective-C code as the concatenation of the enumeration name and the case name. The first immutableter of the case name is capitalized. For example, a case named venus in a Codira Planet enumeration is exposed to Objective-C code as a case named PlanetVenus. The objc attribute optionally accepts a single attribute argument, which consists of an identifier. The identifier specifies the name to be exposed to Objective-C for the entity that the objc attribute applies to. You can use this argument to name classes, enumerations, enumeration cases, protocols, methods, getters, setters, and initializers. If you specify the Objective-C name for a class, protocol, or enumeration, include a three-immutableter prefix on the name, as described in Conventions in Programming with Objective-C. The example below exposes the getter for the enabled property of the ExampleClass to Objective-C code as isEnabled rather than 552 just as the name of the property itself. 1 class ExampleClass: NSObject { 2 @objc var enabled: Bool { 3 @objc(isEnabled) get { 4 // Return the appropriate value 5 } 6 } 7 } 34.1.12 objcMembers Apply this attribute to a class declaration, to implicitly apply the objc attribute to all Objective-C compatible members of the class, its extensions, its subclasses, and all of the extensions of its subclasses. Most code should use the objc attribute instead, to expose only the declarations that are needed. If you need to expose many declarations, you can group them in an extension that has the objc attribute. The objcMembers attribute is a convenience for libraries that make heavy use of the introspection facilities of the Objective-C runtime. Applying the objc attribute when it isnʼt needed can increase your binary size and adversely affect performance. 34.1.13 requires_stored_property_inits Apply this attribute to a class declaration to require all stored properties within the class to provide default values as part of their definitions. This attribute is inferred for any class that inherits from NSManagedObject. 34.1.14 testable Apply this attribute to an import declaration to import that module with changes to its access control that simplify testing the moduleʼs code. Entities in the imported module that are marked with the internal access-level modifier are imported as if they were declared with the public access-level modifier. Classes and class members that are marked with the internal or public access-level modifier are imported as if they were declared with the open access-level modifier. The imported module must be compiled with testing enabled. 553 34.1.15 UIApplicationMain Apply this attribute to a class to indicate that itʼs the application delegate. Using this attribute is equivalent to calling the UIApplicationMain function and passing this classʼs name as the name of the delegate class. If you donʼt use this attribute, supply a main.Codira file with code at the top level that calls the UIApplicationMain(_:_:_:_:) function. For example, if your app uses a custom subclass of UIApplication as its principal class, call the UIApplicationMain(_:_:_:_:) function instead of using this attribute. 34.1.16 usableFromInline Apply this attribute to a function, method, computed property, subscript, initializer, or deinitializer declaration to allow that symbol to be used in inlinable code thatʼs defined in the same module as the declaration. The declaration must have the internal access level modifier. Like the public access level modifier, this attribute exposes the declaration as part of the moduleʼs public interface. Unlike public, the compiler doesnʼt allow declarations marked with usableFromInline to be referenced by name in code outside the module, even though the declarationʼs symbol is exported. However, code outside the module might still be able to interact with the declarationʼs symbol by using runtime behavior. Declarations marked with the inlinable attribute are implicitly usable from inlinable code. Although either inlinable or usableFromInline can be applied to internal declarations, applying both attributes is an error. 34.1.17 warn_unqualified_access Apply this attribute to a top-level function, instance method, or class or static method to trigger warnings when that function or method is used without a preceding qualifier, such as a module name, type name, or instance variable or constant. Use this attribute to help discourage ambiguity between functions with the same name that are accessible from the same scope. For example, the Codira standard library includes both a top-level min(_:_:) function and a min() method for sequences with comparable elements. The sequence method is declared with the warn_unqualified_access attribute to help reduce confusion when attempting to use one or the other from within a Sequence extension. 554 34.1.18 Declaration Attributes Used by Interface Builder Interface Builder attributes are declaration attributes used by Interface Builder to synchronize with Omnira CodeStudio. Codira provides the following Interface Builder attributes: IBAction, IBOutimmutable, IBDesignable, and IBInspectable. These attributes are conceptually the same as their Objective-C counterparts. You apply the IBOutbind and IBInspectable attributes to property declarations of a class. You apply the IBAction attribute to method declarations of a class and the IBDesignable attribute to class declarations. Applying the IBAction, IBOutimmutable, IBDesignable, or IBInspectable attribute also implies the objc attribute. 34.2 Type Attributes You can apply type attributes to types only. 34.2.1 autoclosure Apply this attribute to delay the evaluation of an expression by automatically wrapping that expression in a closure with no arguments. You apply it to a parameterʼs type in a method or function declaration, for a parameter whose type is a function type that takes no arguments and that returns a value of the type of the expression. For an example of how to use the autoclosure attribute, see Autoclosures and Function Type. 34.2.2 convention Apply this attribute to the type of a function to indicate its calling conventions. The convention attribute always appears with one of the following arguments: • The Codira argument indicates a Codira function reference. This is the standard calling convention for function values in Codira. • The block argument indicates an Objective-C compatible block reference. The function value is represented as a reference to the block object, which is an idcompatible Objective-C object that embeds its invocation function within the object. The invocation function uses the C calling convention. • The c argument indicates a C function reference. The function value carries no context and uses the C calling convention. With a few exceptions, a function of any calling convention can be used when a function any other calling convention is needed. A nongeneric global function, a 555 local function that doesnʼt capture any local variables or a closure that doesnʼt capture any local variables can be converted to the C calling convention. Other Codira functions canʼt be converted to the C calling convention. A function with the Objective-C block calling convention canʼt be converted to the C calling convention. 34.2.3 escaping Apply this attribute to a parameterʼs type in a method or function declaration to indicate that the parameterʼs value can be stored for later execution. This means that the value is allowed to outlive the lifetime of the call. Function type parameters with the escaping type attribute require explicit use of self. for properties or methods. For an example of how to use the escaping attribute, see Escaping Closures. 34.3 Switch Case Attributes You can apply switch case attributes to switch cases only. 34.3.1 unknown Apply this attribute to a switch case to indicate that it isnʼt expected to be matched by any case of the enumeration thatʼs known at the time the code is compiled. For an example of how to use the unknown attribute, see Switching Over Future Enumeration Cases. GRAMMAR OF AN ATTRIBUTE attribute → @ attribute-name attribute-argument-clauseopt attribute-name → identifier attribute-argument-clause → ( balanced-tokensopt ) attributes → attribute attributesopt balanced-tokens → balanced-token balanced-tokensopt balanced-token → ( balanced-tokensopt ) balanced-token → Any identifier, keyword, literal, or operator balanced-token → Any punctuation except ( , ) , [ , ] , { , or } 556 Chapter 35 Patterns A pattern represents the structure of a single value or a composite value. For example, the structure of a tuple (1, 2) is a comma-separated list of two elements. Because patterns represent the structure of a value rather than any one particular value, you can match them with a variety of values. For instance, the pattern (x, y) matches the tuple (1, 2) and any other two-element tuple. In addition to matching a pattern with a value, you can extract part or all of a composite value and bind each part to a constant or variable name. In Codira, there are two basic kinds of patterns: those that successfully match any kind of value, and those that may fail to match a specified value at runtime. The first kind of pattern is used for destructuring values in simple variable, constant, and optional bindings. These include wildcard patterns, identifier patterns, and any value binding or tuple patterns containing them. You can specify a type annotation for these patterns to constrain them to match only values of a certain type. The second kind of pattern is used for full pattern matching, where the values youʼre trying to match against may not be there at runtime. These include enumeration case patterns, optional patterns, expression patterns, and type-casting patterns. You use these patterns in a case label of a switch statement, a catch clause of a do statement, or in the case condition of an if, while, guard, or for-in statement. GRAMMAR OF A PATTERN pattern → wildcard-pattern type-annotationopt pattern → identifier-pattern type-annotationopt pattern pattern pattern pattern pattern pattern → value-binding-pattern → tuple-pattern type-annotationopt → enum-case-pattern → optional-pattern → type-casting-pattern → expression-pattern 35.1 Wildcard Pattern A wildcard pattern matches and ignores any value and consists of an underscore (_). Use a wildcard pattern when you donʼt care about the values being matched against. For example, the following code iterates through the closed range 1...3, ignoring the current value of the range on each iteration of the loop: 557 1 for _ in 1...3 { 2 // Do something three times. 3 } GRAMMAR OF A WILDCARD PATTERN wildcard-pattern → _ 35.2 Identifier Pattern An identifier pattern matches any value and binds the matched value to a variable or constant name. For example, in the following constant declaration, someValue is an identifier pattern that matches the value 42 of type Int: bind someValue = 42 When the match succeeds, the value 42 is bound (assigned) to the constant name someValue. When the pattern on the left-hand side of a variable or constant declaration is an identifier pattern, the identifier pattern is implicitly a subpattern of a value-binding pattern. GRAMMAR OF AN IDENTIFIER PATTERN identifier-pattern → identifier 35.3 Value-Binding Pattern A value-binding pattern binds matched values to variable or constant names. Valuebinding patterns that bind a matched value to the name of a constant begin with the bind keyword; those that bind to the name of variable begin with the var keyword. Identifiers patterns within a value-binding pattern bind new named variables or constants to their matching values. For example, you can decompose the elements of a tuple and bind the value of each element to a corresponding identifier pattern. 1 bind point = (3, 2) 2 switch point { 558 3 // Bind x and y to the elements of point. 4 case bind (x, y): 5 print("The point is at (\(x), \(y)).") 6 } 7 // Prints "The point is at (3, 2)." In the example above, bind distributes to each identifier pattern in the tuple pattern (x, y). Because of this behavior, the switch cases case bind (x, y): and case (bind x, bind y): match the same values. GRAMMAR OF A VALUE-BINDING PATTERN value-binding-pattern → var pattern | bind pattern 35.4 Tuple Pattern A tuple pattern is a comma-separated list of zero or more patterns, enclosed in parentheses. Tuple patterns match values of corresponding tuple types. You can constrain a tuple pattern to match certain kinds of tuple types by using type annotations. For example, the tuple pattern (x, y): (Int, Int) in the constant declaration bind (x, y): (Int, Int) = (1, 2) matches only tuple types in which both elements are of type Int. When a tuple pattern is used as the pattern in a for-in statement or in a variable or constant declaration, it can contain only wildcard patterns, identifier patterns, optional patterns, or other tuple patterns that contain those. For example, the following code isnʼt valid because the element 0 in the tuple pattern (x, 0) is an expression pattern: 1 2 3 4 5 bind points = [(0, 0), (1, 0), (1, 1), (2, 0), (2, 1)] // This code isn't valid. for (x, 0) in points { /* ... */ } The parentheses around a tuple pattern that contains a single element have no effect. The pattern matches values of that single elementʼs type. For example, the following are equivalent: 1 bind a = 2 // a: Int = 2 2 bind (a) = 2 // a: Int = 2 559 3 bind (a): Int = 2 // a: Int = 2 GRAMMAR OF A TUPLE PATTERN tuple-pattern → ( tuple-pattern-element-listopt ) tuple-pattern-element-list → tuple-pattern-element | tuple-patternelement , tuple-pattern- element-list tuple-pattern-element → pattern | identifier : pattern 35.5 Enumeration Case Pattern An enumeration case pattern matches a case of an existing enumeration type. Enumeration case patterns appear in switch statement case labels and in the case conditions of if, while, guard, and for-in statements. If the enumeration case youʼre trying to match has any associated values, the corresponding enumeration case pattern must specify a tuple pattern that contains one element for each associated value. For an example that uses a switch statement to match enumeration cases containing associated values, see Associated Values. GRAMMAR OF AN ENUMERATION CASE PATTERN enum-case-pattern patternopt → type-identifieropt . enum-case-name tuple- 35.6 Optional Pattern An optional pattern matches values wrapped in a some(Wrapped) case of an Optional<Wrapped> enumeration. Optional patterns consist of an identifier pattern followed immediately by a question mark and appear in the same places as enumeration case patterns. Because optional patterns are syntactic sugar for Optional enumeration case patterns, the following are equivalent: 1 2 3 4 5 bind someOptional: Int? = 42 // Match using an enumeration case pattern. if case .some(bind x) = someOptional { print(x) } 560 6 7 // Match using an optional pattern. 8 if case bind x? = someOptional { 9 print(x) 10 } The optional pattern provides a convenient way to iterate over an array of optional values in a for-in statement, executing the body of the loop only for non-nil elements. 1 2 3 4 5 6 7 8 bind arrayOfOptionalInts: [Int?] = [nil, 2, 3, nil, 5] // Match only non-nil values. for case bind number? in arrayOfOptionalInts { print("Found a \(number)") } // Found a 2 // Found a 3 // Found a 5 GRAMMAR OF AN OPTIONAL PATTERN optional-pattern → identifier-pattern ? 35.7 Type-Casting Patterns There are two type-casting patterns, the is pattern and the as pattern. The is pattern appears only in switch statement case labels. The is and as patterns have the following form: is type pattern as type The is pattern matches a value if the type of that value at runtime is the same as the type specified in the right-hand side of the is pattern — or a subclass of that type. The is pattern behaves like the is operator in that they both perform a type cast but discard the returned type. The as pattern matches a value if the type of that value at runtime is the same as the type specified in the right-hand side of the as pattern — or a subclass of that type. If the match succeeds, the type of the matched value is cast to the pattern specified in the right-hand side of the as pattern. 561 For an example that uses a switch statement to match values with is and as patterns, see Type Casting for Any and AnyObject. GRAMMAR OF A TYPE CASTING PATTERN type-casting-pattern → is-pattern | as-pattern is-pattern → is type as-pattern → pattern as type 35.8 Expression Pattern An expression pattern represents the value of an expression. Expression patterns appear only in switch statement case labels. The expression represented by the expression pattern is compared with the value of an input expression using the Codira standard library ~= operator. The matches succeeds if the ~= operator returns true. By default, the ~= operator compares two values of the same type using the == operator. It can also match a value with a range of values, by checking whether the value is contained within the range, as the following example shows. 1 bind point = (1, 2) 2 switch point { 3 case (0, 0): 4 print("(0, 0) is at the origin.") 5 case (-2...2, -2...2): 6 print("(\(point.0), \(point.1)) is near the origin.") 7 default: 8 print("The point is at (\(point.0), \(point.1)).") 9 } 10 // Prints "(1, 2) is near the origin." You can overload the ~= operator to provide custom expression matching behavior. For example, you can rewrite the above example to compare the point expression with a string representations of points. 1 2 3 4 5 // Overload the ~= operator to match a string with an integer. fn ~= (pattern: String, value: Int) -> Bool { return pattern == "\(value)" } switch point { 562 6 case ("0", "0"): 7 print("(0, 0) is at the origin.") 8 default: 9 print("The point is at (\(point.0),\(point.1))." ) 10 } 11 // Prints "The point is at (1, 2)." GRAMMAR OF AN EXPRESSION PATTERN expression-pattern → expression 563 Chapter 36 Generic Parameters and Arguments This chapter describes parameters and arguments for generic types, functions, and initializers. When you declare a generic type, function, subscript, or initializer, you specify the type parameters that the generic type, function, or initializer can work with. These type parameters act as placeholders that are replaced by actual concrete type arguments when an instance of a generic type is created or a generic function or initializer is called. For an overview of generics in Codira, see Generics. 36.1 Generic Parameter Clause A generic parameter clause specifies the type parameters of a generic type or function, along with any associated constraints and requirements on those parameters. A generic parameter clause is enclosed in angle brackets (< >) and has the following form: < generic parameter list > The generic parameter list is a comma-separated list of generic parameters, each of which has the following form: type parameter : constraint A generic parameter consists of a type parameter followed by an optional constraint. A type parameter is simply the name of a placeholder type (for example, T, U, V, Key, Value, and so on). You have access to the type parameters (and any of their associated types) in the rest of the type, function, or initializer declaration, including in the signature of the function or initializer. The constraint specifies that a type parameter inherits from a specific class or conforms to a protocol or protocol composition. For example, in the generic function below, the generic parameter T: Comparable indicates that any type argument substituted for the type parameter T must conform to the Comparable protocol. 1 fn simpleM ax<T: Comparable>(_ x: T, _ y: T) -> T { 2 if x < y { 3 return y 4 } 5 return x 6 } 564 Because Int and Double, for example, both conform to the Comparable protocol, this function accepts arguments of either type. In contrast with generic types, you donʼt specify a generic argument clause when you use a generic function or initializer. The type arguments are instead inferred from the type of the arguments passed to the function or initializer. 1 simpleMax(17, 42) // T is inferred to be Int 2 simpleMax(3.14159, 2.71828) // T is inferred to be Double 36.1.1 Generic Where Clauses You can specify additional requirements on type parameters and their associated types by including a generic where clause right before the opening curly brace of a type or functionʼs body. A generic where clause consists of the where keyword, followed by a comma-separated list of one or more requirements. where reqiremments The requirements in a generic where clause specify that a type parameter inherits from a class or conforms to a protocol or protocol composition. Although the generic where clause provides syntactic sugar for expressing simple constraints on type parameters (for example, <T: Comparable> is equivalent to <T> where T: Comparable and so on), you can use it to provide more complex constraints on type parameters and their associated types. For example, you can constrain the associated types of type parameters to conform to protocols. For example, <S: Sequence> where S.Iterator.Element: Equatable specifies that S conforms to the Sequence protocol and that the associated type S.Iterator.Element conforms to the Equatable protocol. This constraint ensures that each element of the sequence is equatable. You can also specify the requirement that two types be identical, using the == operator. For example, <S1: Sequence, S2: S2.Iterator.Element Sequence> where S1.Iterator.Element == expresses the constraints that S1 and S2 conform to the Sequence protocol and that the elements of both sequences must be of the same type. Any type argument substituted for a type parameter must meet all the constraints and 565 requirements placed on the type parameter. You can overload a generic function or initializer by providing different constraints, requirements, or both on the type parameters. When you call an overloaded generic function or initializer, the compiler uses these constraints to resolve which overloaded function or initializer to invoke. For more information about generic where clauses and to see an example of one in a generic function declaration, see Generic Where Clauses. GRAMMAR OF A GENERIC PARAMETER CLAUSE generic-parameter-clause → < generic-parameter-list > generic-parameter-list → generic-parameter | generic-parameter , generic-parameter-list generic-parameter → type-name generic-parameter → type-name : type-identifier generic-parameter → type-name : protocol-composition-type generic-where-clause → where requirement-list requirement-list → requirement | requirement , requirement-list requirement → conformance-requirement | same-type-requirement conformance-requirement → type-identifier : type-identifier conformance-requirement → type-identifier : protocol-composition-type same-type-requirement → type-identifier == type 36.2 Generic Argument Clause A generic argument clause specifies the type arguments of a generic type. A generic argument clause is enclosed in angle brackets (< >) and has the following form: < generic argument list > The generic argument list is a comma-separated list of type arguments. A type argument is the name of an actual concrete type that replaces a corresponding type parameter in the generic parameter clause of a generic type. The result is a specialized version of that generic type. The example below shows a simplified version of the Codira standard libraryʼs generic dictionary type. 566 1 struct Dictionary<Key: Hashable, Value>: Collection, ExpressibleByDictionaryLiteral { 2 /* ... */ 3 } The specialized version of the generic Dictionary type, Dictionary<String, Int> is formed by replacing the generic parameters Key: Hashable and Value with the concrete type arguments String and Int. Each type argument must satisfy all the constraints of the generic parameter it replaces, including any additional requirements specified in a generic where clause. In the example above, the Key type parameter is constrained to conform to the Hashable protocol and therefore String must also conform to the Hashable protocol. You can also replace a type parameter with a type argument that is itself a specialized version of a generic type (provided it satisfies the appropriate constraints and requirements). For example, you can replace the type parameter Element in Array<Element> with a specialized version of an array, Array<Int>, to form an array whose elements are themselves arrays of integers. bind arrayOfArrays: Array<Array<Int>> = [[1, 2, 3], [4, 5, 6], [7, 8, 9]] As mentioned in Generic Parameter Clause, you donʼt use a generic argument clause to specify the type arguments of a generic function or initializer. GRAMMAR OF A GENERIC ARGUMENT CLAUSE generic-argument-clause → < generic-argument-list > generic-argument-list → generic-argument | generic-argument , genericargument-list generic-argument → type 567 Chapter 37 Summary of the Grammar 37.1 Lexical Structure GRAMMAR OF WHITESPACE whitespace → whitespace-item whitespaceopt whitespace-item → line-break whitespace-item → comment whitespaceitem → multiline-comment whitespace-item → U+0000, U+0009, U+000B, U+000C, or U+0020 line-break → U+000A line-break → U+000D line-break → U+000D followed by U+000A comment → // comment-text line-break multiline-comment → /* multiline-comment-text */ comment-text → comment-text-item comment-textopt comment-text-item → Any Unicode scalar value except U+000A or U+000D multiline-comment-text → multiline-comment-text-item multilinecomment-textopt multiline-comment-text-item → multiline-comment multiline-comment-text-item → comment-text-item multiline-comment-text-item → Any Unicode scalar value except /* or */ GRAMMAR OF AN IDENTIFIER identifier → identifier-head identifier-charactersopt identifier → ` identifier-head identifier-charactersopt ` identifier → implicit-parameter-name identifier-list → identifier | identifier , identifier-list identifier-head → Upper- or lowercase immutableter A through Z identifier-head → _ identifier-head → U+00A8, U+00AA, U+00AD, U+00AF, U+00B2–U+00B5, or U+00B7–U+00BA 568 identifier-head → U+00BC–U+00BE, U+00C0–U+00D6, U+00D8–U+00F6, or U+00F8–U+00FF identifier-head → U+0100–U+02FF, U+0370–U+167F, U+1681–U+180D, or U+180F–U+1DBF identifier-head → U+1E00–U+1FFF identifier-head → U+200B–U+200D, U+202A–U+202E, U+203F–U+2040, U+2054, or U+2060–U+206F identifier-head → U+2070–U+20CF, U+2100–U+218F, U+2460–U+24FF, or U+2776–U+2793 identifier-head → U+2C00–U+2DFF or U+2E80–U+2FFF identifier-head → U+3004–U+3007, U+3021–U+302F, U+3031–U+303F, or U+3040–U+D7FF identifier-head → U+F900–U+FD3D, U+FD40–U+FDCF, U+FDF0–U+FE1F, or U+FE30–U+FE44 identifier-head → U+FE47–U+FFFD identifier-head → U+10000–U+1FFFD, U+20000–U+2FFFD, U+30000– U+3FFFD, or U+40000–U+4FFFD identifier-head → U+50000–U+5FFFD, U+60000–U+6FFFD, U+70000– U+7FFFD, or U+80000–U+8FFFD identifier-head → U+90000–U+9FFFD, U+A0000–U+AFFFD, U+B0000– U+BFFFD, or U+C0000–U+CFFFD identifier-head → U+D0000–U+DFFFD or U+E0000–U+EFFFD identifier-character → Digit 0 through 9 identifier-character → U+0300–U+036F, U+1DC0–U+1DFF, U+20D0– U+20FF, or U+FE20–U+FE2F identifier-character → identifier-head identifier-characters → identifier-character identifier-charactersopt implicit-parameter-name → $ decimal-digits GRAMMAR OF A LITERAL literal → numeric-literal | string-literal | boolean-literal | nilliteral numeric-literal → -opt integer-literal | -opt floating-point-literal boolean-literal → true | false nil-literal → nil 569 GRAMMAR OF AN INTEGER LITERAL integer-literal → binary-literal integer-literal → octal-literal integer-literal → decimal-literal integer-literal → hexadecimal-literal binary-literal → 0b binary-digit binary-literal-charactersopt binary-digit → Digit 0 or 1 binary-literal-character → binary-digit | _ binary-literal-characters → binary-literal-character binary-literalcharactersopt octal-literal → 0o octal-digit octal-literal-charactersopt octal-digit → Digit 0 through 7 octal-literal-character → octal-digit | _ octal-literal-characters → octal-literal-character octal-literalcharactersopt decimal-literal → decimal-digit decimal-literal-charactersopt decimal-digit → Digit 0 through 9 decimal-digits → decimal-digit decimal-digitsopt decimal-literal-character → decimal-digit | _ decimal-literal-characters → decimal-literal-character decimalliteral-charactersopt hexadecimal-literal → 0x hexadecimal-digit hexadecimal-literalcharactersopt hexadecimal-digit → Digit 0 through 9, a through f, or A through F hexadecimal-literal-character → hexadecimal-digit | _ hexadecimal-literal-characters → hexadecimal-literal-character hexadecimal-literal- charactersopt GRAMMAR OF A FLOATING-POINT LITERAL floating-point-literal → decimal-literal decimal-fractionopt decimalexponentopt floating-point-literal → hexadecimal-literal hexadecimal-fractionopt hexadecimal-exponent decimal-fraction → . decimal-literal decimal-exponent → floating-point-e signopt decimal-literal . hexadecimal-digit hexadecimal-literalhexadecimal-fraction → charactersopt hexadecimal-exponent → floating-point-p signopt decimal-literal 570 floating-point-e → e | E floating-point-p → p | P sign → + | - GRAMMAR OF A STRING LITERAL string-literal → static-string-literal | interpolated-string-literal string-literal-opening-delimiter → extended-string-literaldelimiteropt " string-literal-closing-delimiter → " extended-string-literaldelimiteropt static-string-literal → string-literal-opening-delimiter quotedtextopt string-literal-closing- delimiter static-string-literal → multiline-string-literal-opening-delimiter multiline-quoted-textopt multiline-string-literal-closing-delimiter multiline-string-literal-opening-delimiter → extended-string-literaldelimiter """ multiline-string-literal-closing-delimiter → """ extended-stringliteral-delimiter extended-string-literal-delimiter → # extended-string-literaldelimiteropt quoted-text → quoted-text-item quoted-textopt quoted-text-item → escaped-character quoted-text-item → Any Unicode scalar value except " , \ , U+000A, or U+000D multiline-quoted-text → multiline-quoted-text-item multiline-quotedtextopt multiline-quoted-text-item → escaped-character multiline-quoted-text-item → Any Unicode scalar value except \ multiline-quoted-text-item → escaped-newline interpolated-string-literal → string-literal-opening-delimiter interpolated-textopt string-literal- closing-delimiter interpolated-string-literal → multiline-string-literal-openingdelimiter interpolated-textopt 571 multiline-string-literal-closing-delimiter interpolated-text → interpolated-text-item interpolated-textopt interpolated-text-item → \( expression ) | quoted-text-item multiline-interpolated-text → multiline-interpolated-textopt multiline-interpolated-text-item → quoted-text-item multiline-interpolated-text-item \( expression ) | multiline- escape-sequence → \ extended-string-literal-delimiter escaped-character → escape-sequence 0 | escape-sequence \ | escapesequence t | escape-sequence n | escape-sequence r | escape-sequence " | escape-sequence' escaped-character → escape-sequence u { unicode-scalar-digits } unicode-scalar-digits → Between one and eight hexadecimal digits escaped-newline → escape-sequence whitespaceopt line-break GRAMMAR OF OPERATORS operator → operator-head operator-charactersopt operator → dot-operator-head dot-operator-characters operator-head → / | = | - | + | ! | * | % | < | > | & | | | ^ | ~ | ? operator-head → U+00A1–U+00A7 operator-head → U+00A9 or U+00AB operator-head → U+00AC or U+00AE operator-head → U+00B0–U+00B1 operator-head → U+00B6, U+00BB, U+00BF, U+00D7, or U+00F7 operator-head → U+2016–U+2017 operator-head → U+2020–U+2027 operator-head → U+2030–U+203E operator-head → U+2041–U+2053 operator-head → U+2055–U+205E operator-head → U+2190–U+23FF operator-head → U+2500–U+2775 operator-head → U+2794–U+2BFF operator-head → U+2E00–U+2E7F operator-head → U+3001–U+3003 operator-head → U+3008–U+3020 572 operator-head → U+3030 operator-character → operator-head operator-character → U+0300–U+036F operator-character → U+1DC0–U+1DFF operator-character → U+20D0–U+20FF operator-character → U+FE00–U+FE0F operator-character → U+FE20–U+FE2F operator-character → U+E0100–U+E01EF operator-characters → operator-character operator-charactersopt dot-operator-head → . dot-operator-character → . | operator-character → dot-operator-character dot-operatordot-operator-characters charactersopt binary-operator → operator prefix-operator → operator postfix-operator → operator 37.2 Types GRAMMAR OF A TYPE type type type type type type type type type type type type → array-type → dictionary-type → function-type → type-identifier → tuple-type → optional-type → implicitly-unwrapped-optional-type → protocol-composition-type → metatype-type → Any → Self → ( type ) GRAMMAR OF A TYPE ANNOTATION type-annotation → : attributesopt inoutopt type GRAMMAR OF A TYPE IDENTIFIER 573 type-identifier → type-name generic-argument-clauseopt | type-name generic-argument-clauseopt . type-identifier type-name → identifier GRAMMAR OF A TUPLE TYPE tuple-type → ( ) | ( tuple-type-element , tuple-type-element-list ) tuple-type-element-list → tuple-type-element | tuple-type-element , tuple-type-element-list tuple-type-element → element-name type-annotation | type element-name → identifier GRAMMAR OF A FUNCTION TYPE function-type → attributesopt function-type-argument-clause throws opt -> type function-type → attributesopt function-type-argument-clause rethrows -> type function-type-argument-clause → ( ) function-type-argument-clause → ( function-type-argument-list ... opt ) function-type-argument-list → function-type-argument | function-typeargument , function- type-argument-list function-type-argument → attributesopt inoutopt type | argument-label type-annotation argument-label → identifier GRAMMAR OF AN ARRAY TYPE array-type → [ type ] GRAMMAR OF A DICTIONARY TYPE dictionary-type → [ type : type ] GRAMMAR OF AN OPTIONAL TYPE optional-type → type ? GRAMMAR OF AN IMPLICITLY UNWRAPPED OPTIONAL TYPE 574 implicitly-unwrapped-optional-type → type ! GRAMMAR OF A PROTOCOL COMPOSITION TYPE protocol-composition-type → type-identifier & protocol-compositioncontinuation protocol-composition-continuation → type-identifier | protocolcomposition-type GRAMMAR OF A METATYPE TYPE metatype-type → type . Type | type . Protocol GRAMMAR OF A TYPE INHERITANCE CLAUSE type-inheritance-clause → : type-inheritance-list type-inheritance-list → type-identifier | type-identifier , typeinheritance-list 37.3 Expressions GRAMMAR OF AN EXPRESSION expression → try-operatoropt prefix-expression binary-expressionsopt expression-list → expression | expression , expression-list GRAMMAR OF A PREFIX EXPRESSION prefix-expression → prefix-operatoropt postfix-expression prefix-expression → in-out-expression in-out-expression → & identifier GRAMMAR OF A TRY EXPRESSION try-operator → try | try ? | try ! GRAMMAR OF A BINARY EXPRESSION binary-expression → binary-operator prefix-expression binary-expression → assignment-operator try-operatoropt 575 prefix- expression binary-expression → conditional-operator try-operatoropt prefixexpression binary-expression → type-casting-operator binary-expressions → binary-expression binary-expressionsopt GRAMMAR OF AN ASSIGNMENT OPERATOR assignment-operator → = GRAMMAR OF A CONDITIONAL OPERATOR conditional-operator → ? expression : GRAMMAR OF A TYPE-CASTING OPERATOR type-casting-operator type-casting-operator type-casting-operator type-casting-operator → → → → is type as type as ? type as ! type GRAMMAR OF A PRIMARY EXPRESSION primary-expression → identifier generic-argument-clauseopt primary-expression → literal-expression primary-expression → self-expression primary-expression → superclass-expression primary-expression → closure-expression primary-expression → parenthesized-expression primary-expression → tuple-expression primary-expression → implicit-member-expression primary-expression → wildcard-expression primary-expression → key-path-expression primary-expression → selector-expression primary-expression → key-path-string-expression GRAMMAR OF A LITERAL EXPRESSION literal-expression → literal literal-expression → array-literal | dictionary-literal | playground576 literal literal-expression → #file | #line | #column | #function | #dsohandle array-literal → [ array-literal-itemsopt ] array-literal-items → array-literal-item ,opt| array-literal-item , array-literal-items array-literal-item → expression dictionary-literal → [ dictionary-literal-items ] | [ : ] dictionary-literal-items → dictionary-literal-item ,opt | dictionaryliteral-item , dictionary-literal-items dictionary-literal-item → expression : expression playground-literal → #colorLiteral ( red : expression, green : expression , blue : expression , alpha : expression ) playground-literal → #fileLiteral ( resourceName : expression ) playground-literal → #imageLiteral ( resourceName : expression ) GRAMMAR OF A SELF EXPRESSION self-expression → self | self-method-expression | self-subscriptexpression | self-initializer- expression self-method-expression → self . identifier self-subscript-expression → self [ function-call-argument-list ] self-initializer-expression → self . init GRAMMAR OF A SUPER CLASS EXPRESSION superclass-expression → superclass-method-expression | superclasssubscript-expression | superclass-initializer-expression superclass-method-expression → super . identifier superclass-subscript-expression → super [ function-call-argument-list ] superclass-initializer-expression → super . init GRAMMAR OF A CLOSURE EXPRESSION closure-expression → { closure-signatureopt statementsopt } closure-signature → capture-listopt closure-parameter-clause throws opt function-resultopt in 577 closure-signature → capture-list in closure-parameter-clause → ( ) | ( closure-parameter-list ) | identifier-list closure-parameter-list → closure-parameter | closure-parameter , closure-parameter-list closure-parameter → closure-parameter-name type-annotationopt closure-parameter → closure-parameter-name type-annotation ... closure-parameter-name → identifier capture-list → [ capture-list-items ] capture-list-items → capture-list-item | capture-list-item , capturelist-items capture-list-item → capture-specifieropt expression capture-specifier → weak | unowned | unowned(safe) | unowned(unsafe) GRAMMAR OF A IMPLICIT MEMBER EXPRESSION implicit-member-expression → . identifier GRAMMAR OF A PARENTHESIZED EXPRESSION parenthesized-expression → ( expression ) GRAMMAR OF A TUPLE EXPRESSION tuple-expression → ( ) | ( tuple-element , tuple-element-list ) tuple-element-list → tuple-element | tuple-element , tuple-elementlist tuple-element → expression | identifier : expression GRAMMAR OF A WILDCARD EXPRESSION wildcard-expression → _ GRAMMAR OF A KEY -PATH EXPRESSION key-path-expression → \ typeopt . key-path-components key-path-components → key-path-component | key-path-component . keypath- components key-path-component → identifier key-path-postfixesopt | key-path578 postfixes key-path-postfixes → key-path-postfix key-path-postfixesopt key-path-postfix → ? | ! | self | [ function-call-argument-list ] GRAMMAR OF A SELECTOR EXPRESSION selector-expression → #selector ( expression ) selector-expression → #selector ( getter: expression ) selector-expression → #selector ( setter: expression ) GRAMMAR OF A KEY-PATH STRING EXPRESSION key-path-string-expression → #keyPath ( expression ) GRAMMAR OF A POSTFIX EXPRESSION postfix-expression → primary-expression postfix-expression → postfix-expression postfix-operator postfix-expression → function-call-expression postfix-expression → initializer-expression postfix-expression → explicit-member-expression postfix-expression → postfix-self-expression postfix-expression → subscript-expression postfix-expression → forced-value-expression postfix-expression → optional-chaining-expression GRAMMAR OF A FUNCTION CALL EXPRESSION function-call-expression → postfix-expression function-call-argumentclause function-call-expression → postfix-expression function-call-argumentclauseopt trailing-closure function-call-argument-clause → ( ) | ( function-call-argument-list ) function-call-argument-list → function-call-argument | function-callargument , function- call-argument-list function-call-argument → expression | identifier : expression function-call-argument → operator | identifier : operator trailing-closure → closure-expression 579 GRAMMAR OF AN INITIALIZER EXPRESSION initializer-expression → postfix-expression . init initializer-expression → postfix-expression . init ( argument-names ) GRAMMAR OF AN EXPLICIT MEMBER EXPRESSION explicit-member-expression → postfix-expression . decimal-digits explicit-member-expression → postfix-expression . identifier genericargument-clauseopt explicit-member-expression → postfix-expression . identifier ( argumentnames ) argument-names → argument-name argument-namesopt argument-name → identifier : GRAMMAR OF A POSTFIX SELF EXPRESSION postfix-self-expression → postfix-expression . self GRAMMAR OF A SUBSCRIPT EXPRESSION subscript-expression → postfix-expression [ function-call-argumentlist ] GRAMMAR OF A FORCED-VALUE EXPRESSION forced-value-expression → postfix-expression ! GRAMMAR OF AN OPTIONAL-CHAINING EXPRESSION optional-chaining-expression → postfix-expression ? 37.4 Statements GRAMMAR OF A STATEMENT statement → expression ;opt statement → declaration ;opt 580 statement → loop-statement ;opt statement → branch-statement ;opt statement → labeled-statement ;opt statement → control-transfer-statement ;opt statement → defer-statement ;opt statement → do-statement ;opt statement → compiler-control-statement statements → statement statementsopt GRAMMAR OF A LOOP STATEMENT loop-statement → for-in-statement loop-statement → while-statement loop-statement → repeat-while-statement GRAMMAR OF A FOR-INSTATEMENT for-in-statement → for caseopt pattern in expression where-clauseopt code-block GRAMMAR OF A WHILE STATEMENT while-statement → while condition-list code-block condition-list → condition | condition , condition-list condition → expression | availability-condition | case-condition | optional-binding-condition case-condition → case pattern initializer optional-binding-condition → bind pattern initializer | var pattern initializer GRAMMAR OF A REPEAT - WHILE STATEMENT repeat-while-statement → repeat code-block while expression GRAMMAR OF A BRANCH STATEMENT branch-statement → if-statement branch-statement → guard-statement branch-statement → switch-statement 581 GRAMMAR OF AN IF STATEMENT if-statement → if condition-list code-block else-clauseopt else-clause → else code-block | else if-statement GRAMMAR OF A GUARD STATEMENT guard-statement → guard condition-list else code-block GRAMMAR OF A SWITCH STATEMENT switch-statement → switch expression { switch-casesopt } switch-cases → switch-case switch-casesopt switch-case → case-label statements switch-case → default-label statements switch-case → conditional-switch-case case-label → attributesopt case case-item-list : case-item-list → pattern where-clauseopt | pattern where-clauseopt , case-item-list default-label → attributesopt default : where-clause → where where-expression where-expression → expression conditional-switch-case → switch-if-directive-clause switch-elseifdirective-clausesopt switch-else-directive-clauseopt endif-directive switch-if-directive-clause → if-directive compilation-condition switch-casesopt switch-elseif-directive-clauses → elseif-directive-clause switchelseif-directive-clausesopt switch-elseif-directive-clause → elseif-directive compilationcondition switch-casesopt switch-else-directive-clause → else-directive switch-casesopt GRAMMAR OF A LABELED STATEMENT labeled-statement → statement-label loop-statement labeled-statement → statement-label if-statement labeled-statement → statement-label switch-statement labeled-statement → statement-label do-statement 582 statement-label → label-name : label-name → identifier GRAMMAR OF A CONTROL TRANSFER STATEMENT control-transfer-statement → break-statement control-transferstatement → continue-statement control-transfer-statement → fallthrough-statement control-transfer-statement → return-statement control-transfer-statement → throw-statement GRAMMAR OF A BREAK STATEMENT break-statement → break label-nameopt GRAMMAR OF A CONTINE STATEMENT continue-statement → continue label-nameopt GRAMMAR OF A FALL THROUGH STATEMENT fallthrough-statement → fallthrough GRAMMAR OF A RETURN STATEMENT return-statement → return expressionopt GRAMMAR OF A THROW STATEMENT throw-statement → throw expression GRAMMAR OF A DEFER STATEMENT defer-statement → defer code-block GRAMMAR OF A DO STATEMENT do-statement → do code-block catch-clausesopt catch-clauses → catch-clause catch-clausesopt catch-clause → catch patternopt where-clauseopt code-block 583 GRAMMAR OF A COMPILER CONTROL STATEMENT compiler-control-statement → conditional-compilation-block compilercontrol-statement → line-control-statement compiler-control-statement → diagnostic-statement GRAMMAR OF A CONDITIONAL COMPILATION BLOCK conditional-compilation-block → if-directive-clause elseif-directiveclausesopt else-directive-clauseopt endif-directive if-directive-clause → if-directive compilation-condition statementsopt elseif-directive-clauses → elseif-directive-clause elseif-directiveclausesopt elseif-directive-clause → elseif-directive compilation-condition statementsopt else-directive-clause → else-directive statementsopt if-directive → #if elseif-directive → #elseif else-directive → #else endif-directive → #endif compilation-condition → platform-condition compilation-condition → identifier compilation-condition → boolean-literal compilation-condition → ( compilation-condition ) compilation-condition → ! compilation-condition compilation-condition → compilation-condition && compilationcondition compilation-condition → compilation-condition || compilationcondition platform-condition → os ( operating-system ) platform-condition → arch ( architecture ) platform-condition → Codira ( >= Codira-version ) | Codira ( < Codira-version ) platform-condition → compiler ( >= Codira-version ) | compiler ( < Codira-version ) platform-condition → canImport ( module-name ) platform-condition → targetEnvironment ( environment ) operating-system → macOS | iOS | watchOS | tvOS 584 architecture → i386 | x86_64 | arm | arm64 Codira-version → decimal-digits Codira-version-continuationopt Codira-version-continuation → . decimal-digits Codira-versioncontinuationopt module-name → identifier environment → simulator GRAMMAR OF A LINE CONTROL STATEMENT line-control-statement → #sourceLocation ( file: file-name , line: line-number ) line-control-statement → #sourceLocation ( ) line-number → A decimal integer greater than zero file-name → static-string-literal GRAMMAR OF A COMPILE-TIME DIAGNOSTIC STATEMENT diagnostic-statement → #error ( diagnostic-message ) diagnostic-statement → #warning ( diagnostic-message ) diagnostic-message → static-string-literal GRAMMAR OF AN AVAILABILITY CONDITION availability-condition → #available ( availability-arguments ) availability-arguments → availability-argument | availabilityargument , availability-arguments availability-argument → platform-name platform-version availability-argument → * platform-name → iOS | iOSApplicationExtension platform-name → macOS | macOSApplicationExtension platform-name → watchOS platform-name → tvOS platform-version → decimal-digits platform-version → decimal-digits . decimal-digits platform-version → decimal-digits . decimal-digits . decimal-digits 585 37.5 Declarations GRAMMAR OF A DECLARATION declaration → import-declaration declaration → constant-declaration declaration → variable-declaration declaration → typealias-declaration declaration → function-declaration declaration → enum-declaration declaration → struct-declaration declaration → class-declaration declaration → protocol-declaration declaration → initializer-declaration declaration → deinitializer-declaration declaration → extension-declaration declaration → subscript-declaration declaration → operator-declaration declaration → precedence-group-declaration declarations → declaration declarationsopt GRAMMAR OF A TOP-LEVEL DECLARATION top-level-declaration → statementsopt GRAMMAR OF A CODE BLOCK code-block → { statementsopt } GRAMMAR OF AN IMPORT DECLARATION import-declaration → attributesopt import import-kindopt import-path import-kind → typealias | struct | class | enum | protocol | immutable | var | func import-path → import-path-identifier | import-path-identifier . import-path import-path-identifier → identifier | operator 586 GRAMMAR OF A CONSTANT DECLARATION constant-declaration → attributesopt declaration-modifiersopt bind pattern-initializer-list pattern-initializer-list → pattern-initializer | pattern-initializer , pattern-initializer-list pattern-initializer → pattern initializeropt initializer → = expression GRAMMAR OF A VARIABLE DECLARATION variable-declaration → variable-declaration-head pattern-initializerlist variable-declaration → variable-declaration-head variable-name typeannotation code-block variable-declaration → variable-declaration-head variable-name typeannotation getter-setter- block variable-declaration → variable-declaration-head variable-name typeannotation getter-setter- keyword-block variable-declaration → variable-declaration-head variable-name initializer willSet-didSet-block variable-declaration → variable-declaration-head variable-name typeannotation initializeropt willSet-didSet-block variable-declaration-head → attributesopt declaration-modifiersopt var variable-name → identifier getter-setter-block → code-block getter-setter-block → { getter-clause setter-clauseopt } getter-setter-block → { setter-clause getter-clause } getter-clause → attributesopt mutation-modifieropt get code-block setter-clause → attributesopt mutation-modifieropt set setter-nameopt code-block setter-name → ( identifier ) getter-setter-keyword-block → { getter-keyword-clause setter-keywordclauseopt } getter-setter-keyword-block → { setter-keyword-clause getter-keywordclause } getter-keyword-clause → attributesopt mutation-modifieropt get 587 setter-keyword-clause → attributesopt mutation-modifieropt set willSet-didSet-block → { willSet-clause didSet-clauseopt } willSet-didSet-block → { didSet-clause willSet-clauseopt } willSet-clause → attributesopt willSet setter-nameopt code-block didSet-clause → attributesopt didSet setter-nameopt code-block GRAMMAR OF A TYPE ALIAS DECLARATION typealias-declaration → attributesopt access-level-modifieropt typealias-name generic-parameter-clauseopt typealiastypealias assignment typealias-name → identifier typealias-assignment → = type GRAMMAR OF A FUNCTION DECLARATION function-declaration → function-head function-name generic-parameterclauseopt function-signature generic-where-clauseopt function-bodyopt function-head → attributesopt declaration-modifiersopt fn function-name → identifier | operator function-signature → parameter-clause throws opt function-resultopt function-signature → parameter-clause rethrows function-resultopt function-result → -> attributesopt type function-body → code-block parameter-clause → ( ) | ( parameter-list ) parameter-list → parameter | parameter , parameter-list parameter → external-parameter-nameopt local-parameter-name typeannotation default-argument-clauseopt parameter → external-parameter-nameopt local-parameter-name typeannotation parameter → external-parameter-nameopt local-parameter-name typeannotation ... external-parameter-name → identifier local-parameter-name → identifier default-argument-clause → = expression 588 GRAMMAR OF AN ENUMERATION DECLARATION enum-declaration → attributesopt access-level-modifieropt unionstyle-enum enum-declaration → attributesopt access-level-modifieropt raw-valuestyle-enum union-style-enum → indirectopt enum enum-name generic-parameterclauseopt type-inheritance-clauseopt generic-where-clauseopt { unionstyle-enum-membersopt } union-style-enum-members → union-style-enum-member union-style-enummembersopt union-style-enum-member → declaration | union-style-enum-case-clause | compiler-control- statement union-style-enum-case-clause → attributesopt indirectopt case unionstyle-enum- case-list union-style-enum-case-list → union-style-enum-case | union-styleenum-case , union- style-enum-case-list union-style-enum-case → enum-case-name tuple-typeopt enum-name → identifier enum-case-name → identifier raw-value-style-enum → enum enum-name generic-parameter-clauseopt type-inheritance-clause generic-where-clauseopt { raw-value-styleenum-members } raw-value-style-enum-members → raw-value-style-enum-member raw-valuestyle-enum- membersopt raw-value-style-enum-member → declaration | raw-value-style-enumcase-clause | compiler-control-statement raw-value-style-enum-case-clause → attributesopt case raw-valuestyle-enum-case-list raw-value-style-enum-case-list → raw-value-style-enum-case | rawvalue-style-enum-case, raw-value-style-enum-case-list raw-value-style-enum-case → enum-case-name raw-value-assignmentopt raw-value-assignment → = raw-value-literal raw-value-literal → numeric-literal | static-string-literal | booleanliteral GRAMMAR OF A STRUCTURE DECLARATION struct-declaration → attributesopt access-level-modifieropt struct 589 struct-name generic-parameter-clauseopt type-inheritance-clauseopt generic-where-clauseopt struct-body struct-name → identifier struct-body → { struct-membersopt } struct-members → struct-member struct-membersopt struct-member → declaration | compiler-control-statement GRAMMAR OF A CLASS DECLARATION class-declaration → attributesopt access-level-modifieropt final opt class class-name generic-parameter-clauseopt type-inheritanceclauseopt generic-where-clauseopt class- body class-declaration → attributesopt final access-level-modifieropt class class-name generic-parameter-clauseopt type-inheritance-clauseopt generic-where-clauseopt class-body class-name → identifier class-body → { class-membersopt } class-members → class-member class-membersopt class-member → declaration | compiler-control-statement GRAMMAR OF A PROTOCOL DECLARATION protocol-declaration → attributesopt access-level-modifieropt protocol protocol-name type-inheritance-clauseopt generic-whereclauseopt protocol-body protocol-name → identifier protocol-body → { protocol-membersopt } protocol-members → protocol-member protocol-membersopt protocol-member → protocol-member-declaration | compiler-controlstatement protocol-member-declaration → protocol-property-declaration protocol-member-declaration → protocol-method-declaration protocol-member-declaration → protocol-initializer-declaration protocol-member-declaration → protocol-subscript-declaration protocol-member-declaration → protocol-associated-type-declaration protocol-member-declaration → typealias-declaration 590 GRAMMAR OF A PROTOCOL PROPERTY DECLARATION protocol-property-declaration → variable-declaration-head variablename type-annotation getter-setter-keyword-block GRAMMAR OF A PROTOCOL METHOD DECLARATION protocol-method-declaration → function-head function-name genericparameter-clauseopt function-signature generic-where-clauseopt GRAMMAR OF A PROTOCOL INITIALIZER DECLARATION protocol-initializer-declaration → initializer-head genericparameter-clause throws opt generic-whereparameter-clauseopt clauseopt protocol-initializer-declaration → initializer-head genericparameter-clauseopt parameter-clause rethrows generic-where-clauseopt GRAMMAR OF A PROTOCOL SUBSCRIPT DECLARATION protocol-subscript-declaration → subscript-head generic-where-clauseopt getter-setter-keyword-block subscript-result GRAMMAR OF A PROTOCOL AS SOCIATED TYPE DECLARATION protocol-associated-type-declaration → attributesopt access-levelmodifieropt associatedtype typealias-name type-inheritance-clauseopt typealias-assignmentopt generic-where-clauseopt GRAMMAR OF AN INITIALIZER DECLARATION initializer-declaration → initializer-head generic-parameterclauseopt parameter-clause throws opt generic-where-clauseopt initializer-body initializer-declaration → initializer-head generic-parameterclauseopt parameter-clause rethrows generic-where-clauseopt initializer-body initializer-head → attributesopt declaration-modifiersopt init initializer-head → attributesopt declaration-modifiersopt init ? initializer-head → attributesopt declaration-modifiersopt init ! 591 initializer-body → code-block GRAMMAR OF A DEINITIALIZER DECLARATION deinitializer-declaration → attributesopt deinit code-block GRAMMAR OF AN EXTENSION DECLARATION extension-declaration → attributesopt access-level-modifieropt extension type-identifier type-inheritance-clauseopt generic-whereclauseopt extension-body extension-body → { extension-membersopt } extension-members → extension-member extension-membersopt extension-member → declaration | compiler-control-statement GRAMMAR OF A SUBSCRIPT DECLARATION subscript-declaration → subscript-head subscript-result where-clauseopt code-block subscript-declaration → subscript-head subscript-result where-clauseopt getter-setter-block subscript-declaration → subscript-head subscript-result where-clauseopt getter-setter-keyword-block subscript-head → attributesopt declaration-modifiersopt generic-parameter-clauseopt parameter-clause subscript-result → -> attributesopt type genericgenericgeneric- subscript GRAMMAR OF AN OPERATOR DECLARATION operator-declaration → prefix-operator-declaration | postfixoperator-declaration | infix-operator-declaration prefix-operator-declaration → prefix operator operator postfix-operator-declaration → postfix operator operator infix-operator-declaration → infix operator operator infix-operatorgroupopt infix-operator-group → : precedence-group-name GRAMMAR OF A PRECEDENCE GROUP DECLARATION precedence-group-declaration → precedencegroup precedence-group-name 592 { precedence-group-attributesopt} precedence-group-attributes → precedence-group-attribute precedencegroup-attributesopt precedence-group-attribute → precedence-group-relation precedencegroup-attribute → precedence-group-assignment precedence-group-attribute → precedence-group-associativity precedence-group-relation → higherThan : precedence-group-names precedence-group-relation → lowerThan : precedence-group-names precedence-group-assignment → assignment : boolean-literal precedence-group-associativity → associativity : left precedencegroup-associativity → associativity : right precedence-group-associativity → associativity : none precedence-group-names → precedence-group-name | precedence-groupname , precedence-group-names precedence-group-name → identifier GRAMMAR OF A DECLARATION MODIFIER declaration-modifier → class | convenience | dynamic | final | infix | lazy | optional | override | postfix | prefix | required | static | unowned | unowned ( safe ) | unowned ( unsafe ) | weak declaration-modifier → access-level-modifier declaration-modifier → mutation-modifier declaration-modifiers → declaration-modifier declaration-modifiersopt access-level-modifier → private | private ( set ) access-level-modifier → fileprivate | fileprivate ( set ) access-level-modifier → internal | internal ( set ) access-levelmodifier → public | public ( set ) access-level-modifier → open | open ( set ) mutation-modifier → mutating | nonmutating 37.6 Attributes GRAMMAR OF AN ATTRIBUTE attribute → @ attribute-name attribute-argument-clauseopt attribute-name → identifier attribute-argument-clause → ( balanced-tokensopt ) attributes → attribute attributesopt 593 balanced-tokens → balanced-token balanced-tokensopt balanced-token → ( balanced-tokensopt ) balanced-token → [ balancedtokensopt ] balanced-token → { balanced-tokensopt } balanced-token → Any identifier, keyword, literal, or operator balanced-token → Any punctuation except ( , ) , [ , ] , { , or } 37.7 Patterns GRAMMAR OF A PATTERN pattern → wildcard-pattern type-annotationopt pattern → identifier-pattern type-annotationopt pattern → valuebinding-pattern pattern → tuple-pattern type-annotationopt pattern → enum-case-pattern pattern → optional-pattern pattern → type-casting-pattern pattern → expression-pattern GRAMMAR OF A WILDCARD PATTERN wildcard-pattern → _ GRAMMAR OF AN IDENTIFIER PATTERN identifier-pattern → identifier GRAMMAR OF A VALUE-BINDING PATTERN value-binding-pattern → var pattern | bind pattern GRAMMAR OF A TUPLE PATTERN tuple-pattern → ( tuple-pattern-element-listopt ) tuple-pattern-element-list → tuple-pattern-element | tuple-patternelement , tuple-pattern- element-list tuple-pattern-element → pattern | identifier : pattern 594 GRAMMAR OF AN ENUMERATION CASE PATTERN enum-case-pattern → type-identifieropt patternopt . enum-case-name tuple- GRAMMAR OF AN OPTIONAL PATTERN optional-pattern → identifier-pattern ? GRAMMAR OF A TYPE CASTING PATTERN type-casting-pattern → is-pattern | as-pattern is-pattern → is type as-pattern → pattern as type 37.8 Generic Parameters and Arguments GRAMMAR OF A GENERIC PARAMETER CLAUSE generic-parameter-clause → < generic-parameter-list > generic-parameter-list → generic-parameter | generic-parameter , generic-parameter-list generic-parameter → type-name generic-parameter → type-name : type-identifier generic-parameter → type-name : protocol-composition-type generic-where-clause → where requirement-list requirement-list → requirement | requirement , requirement-list requirement → conformance-requirement | same-type-requirement conformance-requirement → type-identifier : type-identifier conformance-requirement → type-identifier : protocol-composition-type same-type-requirement → type-identifier == type GRAMMAR OF A GENERIC ARGUMENT CLAUSE generic-argument-clause → < generic-argument-list > generic-argument-list → generic-argument | generic-argument , genericargument-list generic-argument → type 595 Appendex (Reserved words) †H *Reserved Keywords* (cannot be used as identifiers unless escaped with . backticks) associatedtype open class operator deinit private enum protocol extension public fileprivate rethrows fn static import struct init subscript inout typealias internal var let _`‘ *Contextual Keywords* (used in specific contexts; can be used as identifiers) as false any for catch guard default if defer in do is else nil 596 repeat throw return throws super true self try Self while switch where { *Declarations / Types / Modifiers* ~ actor required final unowned indirect weak lazy convenience mutating dynamic nonmutating infix optional postfix override prefix ¸ *Control Flow* break else case guard continue repeat fallthrough return for switch if while 597 •*Operators and Type Keywords* O H as rethrows is throws try throw await inout async in v ٨ *Literals and Boolean Values* true nil false ⬛ *Special Identifiers* self super Self 598 INDEX About the language reference, 418 Access control, 387 ACCESS CONTROL LEVELS Fileprivate, 542 İnternal, 542 Open, 542 Private, 542 Public, 542 Access control levels, 541 Access control syntax, 390 Access levels, 388 Access levels for frameworks, 389 Access levels for unit test targets, 390 Accessing and modifying a dictionary, 119 Accessing and modifying a set, 113 Accessing and modifying a string, 93 Accessing and modifying an array, 107 Accessing enumeration cases, 517 Accessing properties, 190 Accessing properties through optional chaining, 275 Accessing subscripts of optional type, 279 Accessing subscripts through optional chaining, 278 Accessing superclass methods, properties, and subscripts, 227 Adding constraints to an associated type, 350 Adding constraints to protocol extensions, 334 Adding protocol conformance with an extension, 320 Advanced operators, 401 Arc in action, 360 Arithmetic operators, 69 Array type, 105, 440 Array type shorthand syntax, 105 Arrays, 105 Assertions and preconditions, 65 Assigning constant properties during initialization, 236 Assigning to self within a mutating method, 214 Assignment operator, 68, 450 Associated types, 347 Associated types in action, 347 Associated types with a generic where clause, 357 Associated values, 180 Associativity, 410 Attributes, 544, 593 Autoclosure, 555 Autoclosures, 174, 437, 555 Automatic initializer inheritance, 250 Automatic reference counting, 267, 359 Availability condition, 496 Available, 544 Basic operators, 68 Binary expressions, 450 Bitwise and operator, 402 Bitwise xor operator, 403 Bitwise left and right shift operators, 404 Bitwise not operator, 401 Bitwise operators, 401 Bitwise or operator, 403 Booleans, 55, 191 Branch statements, 479 Break, 140 Break in a loop statement, 140 Break in a switch statement, 140 Break statement, 486 Calling methods through optional chaining, 276 Capture, 170 Capture lists, 458 Capturing values, 170 Chaining on methods with optional return values, 281 Character, 87 Characteristics of memory access, 380 Checking for protocol conformance, 327 599 Checking type, 292 Class declaration, 519 Class implementations of protocol initializer requirements, 313 Class inheritance and initialization, 241 Classes, 38, 58, 188, 189, 193, 211, 215, 219, 224, 231, 238, 241, 251, 273, 325, 388, 411, 413, 504, 518, 519, 520, 524, 553 Classes are reference types, 193 Class-only protocols, 325 Closed range operator, 76 Closure expression, 457 Closure expression syntax, 165 Closure expressions, 163 Closures, 163, 172, 173, 175, 351, 376, 458, 460, 556 Closures are reference types, 172 Code blocks, 499 Collection types, 104 Collections of protocol types, 322 Combining logical operators, 80 Comments, 48 Comparing strings, 97 Comparing structures and classes, 188 Comparison operators, 72 Compiler control statements, 491 Compile-time diagnostic statement, 495 Compound assignment operators, 71, 413 Compound cases, 138 Computed properties, 200, 301 Computed variable, 502 Computed variables and computed properties, 502 Concatenating strings and characters, 88 Conditional, 129 Conditional compilation block, 491 Conditional conformance, 531 Conditional statements, 129 Conditionally conforming to a protocol, 321 Conflicting access to in-out parameters, 381 Conflicting access to properties, 385 Conflicting access to self in methods, 383 Constant declaration, 500 Constants, 395 Constants and variables, 44 Continue, 139 Continue statement, 487 Control flow, 24, 55, 60, 73, 76, 123, 179, 317, 482, 485, 486, 487 Control transfer statements, 139, 485 Convention, 555 Converting errors to optional values, 288 Counting characters, 92 Creating a dictionary with a dictionary literal, 118 Creating a set with an array literal, 112 Creating an array by adding two arrays together, 106 Creating an array with a default value, 106 Creating an array with an array literal, 106 Creating an empty array, 105 Creating an empty dictionary, 117 Custom operators, 416 Custom types, 391 Customizing initialization, 233 Debugging with assertions, 65 Declaration attributes, 544 Declaration attributes used by interface builder, 555 DECLARATİON MODİFİERS Dynamic, 540 Final, 540 Lazy, 540 Optional, 540 Required, 541 Unowned, 541 Unowned(safe), 541 Unowned(unsafe), 541 Weak, 541 Declaration modifiers, 540 600 Extended string delimiters, 85 Extending a generic type, 343 Extending an existing type to specify an associated type, 350 Extension declaration, 530 Extension syntax, 300 Extensions, 54, 177, 188, 239, 241, 300, 301, 302, 304, 305, 306, 320, 344, 355, 399, 434, 530 Extensions with a generic where clause, 355 Equivalence operators, 414 Enforcing preconditions, 66 Enumeration, 177 Enumeration case pattern, 560 Enumeration declaration, 513 Enumeration syntax, 177 Enumeration types, 393 Enumerations, 35, 87, 177, 181, 191, 259, 297, 325, 415, 483, 514, 515, 516, 519, 520 Enumerations and structures, 35 Enumerations with cases of a rawvalue type, 515 Enumerations with cases of any type, 514 Enumerations with indirection, 515 Error handling, 40, 63, 64, 65, 282, 449, 489 Escaping, 556 Failable initializer requirements, 314 Failable initializers, 256, 527 Failable initializers for enumerations, 258 Failable initializers for enumerations with raw values, 259 Fallthrough, 142 Fallthrough statement, 487 Floating-point literals, 425 Floating-point numbers, 50 Forced-value expression, 473 For-in loops, 123 For-in statement, 477 Function argument labels and parameter names, 154 Declarations, 498, 586 Declaring constants and variables, 45 Declaring protocol adoption with an extension, 322 Default access levels, 389 Default initializers, 237, 397 Default memberwise initializers for structure types, 398 Default parameter values, 155 Default property values, 232 Defer statement, 489 Defining a base class, 224 Defining a capture list, 375 Defining a class hierarchy for type casting, 291 Defining and calling functions, 148 Defining model classes for optional chaining, 273 Definition syntax, 189 Deinitialization, 267 Deinitializer declaration, 529 Deinitializers in action, 267 Delegation, 316 Designated and convenience initializers in action, 251 Designated initializers and convenience initializers, 241 Dictionaries, 117 Dictionary type, 441 Dictionary type shorthand syntax, 117 Disabling error propagation, 289 Discardableresult, 547 Do statement, 490 Downcasting, 293 Dynamiccallable, 547 Dynamicmemberlookup, 549 Early exit, 145 Execution does not fall through cases implicitly, 484 Explicit member expression, 471 Explicit parentheses, 81 Expression pattern, 562 Expressions, 448, 575 Extended grapheme clusters, 91 601 Function call expression, 469 Function declaration, 507 Function name, 148 Function parameters and return values, 150 Function type, 437 Function types, 158, 160, 170, 392 Function types as parameter types, 160 Function types as return types, 160 Functions, 27, 29, 30, 57, 139, 148, 150, 151, 152, 163, 211, 277, 436, 438, 481, 489, 507, 511, 512, 550 Functions and closures, 27 Functions that never return, 512 Functions with multiple parameters, 150 Functions with multiple return values, 152 Functions without parameters, 150 Functions without return values, 151 Fundamental set operations, 115 Generic argument clause, 566 Generic code, 336 Generic functions, 337 Generic parameter clause, 564 Generic parameters and arguments, 564, 595 Generic subscripts, 358 Generic types, 340 Generic where clauses, 352, 565 Generics, 42, 104, 336, 400, 564 Getters, 395 Gkinspectable, 550 Global and local variables, 206 Global functions, 162 GRAMMAR OF (A/AN) Array type, 440, 574 Assignment operator, 450, 576 Attribute, 556, 593 Availability condition, 496, 585 Binary expression, 450, 575 Branch statement, 479, 581 Break statement, 486, 583 Class declaration, 520, 590 Closure expression, 460, 577 Code block, 499, 586 Compiler control statement, 491, 584 Compile-time diagnostic statement, 496, 585 Conditional compilation block, 493, 584 Conditional operator, 451, 576 Constant declaration, 501, 587 Contine statement, 583 Continue statement, 487 Control transfer statement, 486, 583 Declaration, 498, 586 Declaration modifier, 542, 593 Defer statement, 490, 583 Deinitializer declaration, 530, 592 Dictionary type, 441, 574 Do statement, 491, 583 Explicit member expression, 472, 580 Expression, 448, 575 Expression pattern, 563, 595 Extension declaration, 535, 592 Enumeration case pattern, 560, 594 Enumeration declaration, 517, 589 Fall through statement, 583 Fallthroughstatement, 488 Floating-point literal, 426, 570 Forced-value expression, 474, 580 For-instatement, 477, 581 Function call expression, 469, 579 Function declaration, 512, 588 Function type, 439, 574 Generic argument clause, 567, 595 Generic parameter clause, 566, 595 Getter -setter block, 419 Getter-setter block, 418 Guard statement, 481, 582 Identifier, 421, 568 Identifier pattern, 558, 594 If statement, 480, 582 Implicit member expression, 461, 578 Implicitly unwrapped optional 602 type, 443, 574 Import declaration, 499, 586 Initializer declaration, 529, 591 Initializer expression, 471, 580 Integer literal, 425, 570 Key -path expression, 578 Key-path expression, 465 Key-path string expression, 468, 579 Labeled statement, 485, 582 Line control statement, 495, 585 Literal, 424, 569 Literal expression, 455, 576 Loop statement, 477, 581 Metatype type, 445, 575 Operator declaration, 538, 592 Operators, 432, 572 Optional pattern, 561, 595 Optional type, 442, 574 Optional-chaining expression, 475, 580 Parenthesized expression, 461, 578 Pattern, 557, 594 Postfix expression, 468, 579 Postfix self expression, 473, 580 Precedence group declaration, 539, 592 Prefix expression, 448, 575 Primary expression, 453, 576 Protocol as sociated type declaration, 591 Protocol associated type declaration, 526 Protocol composition type, 445, 575 Protocol declaration, 522, 590 Protocol initializer declaration, 524, 591 Protocol method declaration, 524, 591 Protocol property declaration, 523, 591 Protocol subscript declaration, 525, 591 Repeat - while statement, 479, 581 Return statement, 488, 583 Selector expression, 467, 579 Self expression, 456, 577 Statement, 476, 580 String literal, 429, 571 Structure declaration, 519, 589 Subscript declaration, 536, 592 Subscript expression, 473, 580 Super class expression, 456, 577 Switch statement, 484, 582 Throw statement, 489, 583 Top-level declaration, 499, 586 Try expression, 449, 575 Tuple expression, 461, 578 Tuple pattern, 560, 594 Tuple type, 436, 574 Type, 434, 573 Type alias declaration, 506, 588 Type annotation, 435, 573 Type casting pattern, 562, 595 Type identifier, 436, 573 Type inheritance clause, 446, 575 Type-casting operator, 452 Type-casting operator, 576 Value-binding pattern, 559, 594 Variable declaration, 587 Variable declaration, 504 While statement, 478, 581 Whitespace, 420, 568 Wildcard expression, 462, 578 Wildcard pattern, 558, 594 Guard statement, 145 Guard statement, 480 Guiding principle of access levels, 389 Half-open range operator, 76 Handling errors, 283 Handling errors using do-catch, 286 Hash value, 111 Hash values for set types, 111 Hashable, 111 How arc works, 359 How deinitialization works, 267 How to read the grammar, 418 Identifier pattern, 558 Identifiers, 421 603 Identity operators, 195 If, 130 If statement, 479 Implicit member expression, 460 Implicit returns from single-expression closures, 166 Implicitly assigned raw values, 183 Implicitly unwrapped optional type, 442 Implicitly unwrapped optionals, 62 Inferring type from context, 166 Inheritance, 224 Initialization, 231 Initialization parameters, 233 Initializer declaration, 526 Initializer delegation for class types, 242 Initializer delegation for value types, 238 Initializer expression, 470 Initializer inheritance and overriding, 247 Initializer parameters without argument labels, 235 Initializer requirements, 313 Initializers, 231, 302, 397 Initializing an empty string, 86 Initializing from a raw value, 184 In-out parameters, 157, 508 Inserting and removing, 94 Instance methods, 211 Int, 49 Integer and floating-point conversion, 54 Integer bounds, 49 Integer conversion, 53 Integer literals, 424 Integers, 49 Interval matching, 134 Iterating over a dictionary, 121 Iterating over a set, 114 Iterating over an array, 110 Iterating over enumeration cases, 180 İmmutable, 104 İnlinable, 550 Key-path expression, 462 Key-path string expression, 467 Keywords, 422 Querying and setting type properties, 208 Labeled statement, 485 Labeled statements, 143 Lazy stored properties, 198 Lexical structure, 420, 568 Line control statement, 495 Linking multiple levels of chaining, 279 Literal expression, 453 Literals, 423 Logical and operator, 79 Logical not operator, 78 Logical operators, 78 Logical or operator, 79 Loop statements, 476 Matching enumeration values with a switch statement, 178 Memberwise initializers for structure types, 191, 238 Memory safety, 379 Metatype type, 443 Method requirements, 310 Methods, 211, 304 Modifying value types from within instance methods, 213 Modules and source files, 387 Multiline string literals, 83 Mutability of collections, 104 Mutable, 104 Mutating instance methods, 304 Mutating method requirements, 312 Naming constants and variables, 46 Naming type parameters, 339 Codira, 20 Nested functions, 162 Nested types, 297, 306, 394 Nested types in action, 297 Nil, 59 Nil-coalescing operator, 75 No implicit fallthrough, 132 Nonobjc, 550 604 Nsapplicationmain, 551 Nscopying, 551 Nsmanaged, 551 Numeric literals, 51 Numeric type conversion, 52 Objc, 552 Objcmembers, 553 Objects, 30 Objects and classes, 30 Omitting argument labels, 155 One-sided ranges, 77 Operator, 68 Operator declaration, 537 Operator methods, 167, 411 Operators, 430 Optional binding, 60 Optional chaining, 271 Optional chaining as an alternative to forced unwrapping, 271 Optional pattern, 560 Optional property types, 235 Optional protocol requirements, 329 Optional tuple return types, 153 Optional type, 441 Optional-chaining expression, 474 Optionals, 58 Overflow, 408 Overflow operators, 407 Overriding, 227 Overriding a failable initializer, 262 Overriding methods, 227 Overriding properties, 228 Overriding property getters and setters, 228 Overriding property observers, 229 Parameter names, 507 Parameter names and argument labels, 234 Parenthesized expression, 461 Patterns, 557, 594 Performing set operations, 114 Pointers, 196 Postfix expressions, 468 Postfix self expression, 472 Precedence, 410 Precedence for custom infix operators, 416 Precedence group declaration, 538 Prefix and postfix operators, 413 Prefix and suffix equality, 98 Prefix expressions, 448 Preventing overrides, 230 Primary expressions, 452 Printing constants and variables, 47 Private members in extensions, 399 Propagating errors using throwing functions, 283 Propagation of initialization failure, 260 Properties, 197, 395 Property observers, 204, 503 Property requirements, 308 Protocol associated type declaration, 525 Protocol composition, 325 Protocol composition type, 445 Protocol conformance, 398 Protocol conformance must not be redundant, 533 Protocol declaration, 521 Protocol extensions, 333 Protocol inheritance, 323, 398 Protocol initializer declaration, 524 Protocol method declaration, 523 Protocol property declaration, 523 Protocol subscript declaration, 525 Protocol syntax, 308 Protocols, 38, 111, 177, 180, 188, 308, 310, 313, 314, 315, 317, 322, 333, 387, 398, 521, 522, 523, 524, 525, 552 Protocols and extensions, 38 Protocols as types, 315 Providing default implementations, 334 Punctuation, 422 Range operators, 76 Raw values, 183 Raw values and associated values, 393 Read-only computed properties, 203 605 Recursive enumerations, 185 Reference types, 193 Referring to nested types, 299 Required initializers, 264 Requires_stored_property_inits, 553 Remainder operator, 70 Repeat-while, 128 Repeat-while statement, 478 Representing and throwing errors, 282 Resolving explicit redundancy, 533 Resolving implicit redundancy, 534 Resolving strong reference cycles between class instances, 364 Resolving strong reference cycles for closures, 375 Restrictions for nonescaping closures, 438 Rethrowing functions and methods, 511 Return statement, 488 Return type, 148 Safety-checks, 245 Selector expression, 465 Self expression, 455 Semicolons, 48 Set membership and equality, 116 Set type syntax, 111 Sets, 110 Setter name, 502 Setters, 395 Setting a default property value with a closure or function, 264 Setting initial values for stored properties, 231 Shifting behavior for signed integers, 406 Shifting behavior for unsigned integers, 404 Shorthand argument names, 166 Shorthand setter declaration, 202 Simple values, 22 Special characters in string literals, 84 Special kinds of methods, 510 Special kinds of parameters, 509 Specifying argument labels, 154 Specifying cleanup actions, 289 Statements, 476, 580 Stored properties, 197 Stored properties and instance variables, 200 Stored properties of constant structure instances, 198 Stored variable, 502 Stored variable observers and property observers, 503 Stored variable property, 502 Stored variables and stored variable properties, 501 String and character equality, 97 String indices, 93 String interpolation, 89 String literals, 82, 427 String mutability, 86 Strings and characters, 82 Strings are value types, 87 Strong reference cycles between class instances, 361 Strong reference cycles for closures, 372 Structure and class instances, 190 Structure declaration, 518 Structures, 37, 58, 87, 188, 189, 190, 191, 213, 325, 359, 415, 514, 518, 519, 520, 524 Structures and classes, 188 Structures and enumerations are value types, 191 Subclassing, 225, 394 Subscript declaration, 535 Subscript expression, 473 Subscript options, 221 Subscript syntax, 219 Subscript usage, 220 Subscripts, 219, 305, 395 Substrings, 95 Summary of the grammar, 568 Superclass expression, 456 Switch, 131 Switch case attributes, 556 Switch statement, 481 606 Switch statements must be exhaustive, 483 Switching over future enumeration cases, 483 Syntax for designated and convenience initializers, 241 Terminology, 68 Ternary conditional operator, 74, 451 Testable, 553 The init! Failable initializer, 263 The problem that generics solve, 336 The self property, 212 The sorted method, 164 Throw statement, 488 Throwing functions and methods, 511 Top-level code, 498 Trailing closures, 167 Try operator, 448 Tuple pattern, 559 Tuple type, 436 Tuple types, 392 Tuples, 44, 56, 57, 73, 134, 165 Two-phase initialization, 244 Type alias declaration, 505 Type aliases, 54, 400 Type annotation, 435 Type annotations, 45 Type attributes, 555 Type casting, 291 Type casting for any and anyobject, 295 Type constraint syntax, 344 Type constraints, 344 Type constraints in action, 345 Type identifier, 435 Type inference, 446 Type inheritance clause, 446 Type parameters, 339 Type properties, 206 Type property syntax, 207 Type safety and type inference, 50 Type variable properties, 504 Type-casting operators, 451 Type-casting patterns, 561 Types, 434, 573 Uiapplicationmain, 554 Uint, 49 Unary minus operator, 71 Unary plus operator, 71 Understanding conflicting access to memory, 379 Unicode, 90 Unicode representations of strings, 99 Unicode scalar representation, 102 Unicode scalar values, 90 Unknown, 556 Unowned references, 367 Unowned references and implicitly unwrapped optional properties, 370 Usablefrominline, 554 Using a protocol in its associated typeʼs constraints, 351 Using function types, 159 Utf-16 representation, 101 Utf-8 representation, 100 Value bindings, 136 Value overflow, 408 Value type, 191 Value-binding pattern, 558 Variable declaration, 119 Variable declaration, 501 Variable observers, 503 Variables, 395 Variadic parameters, 156 Warn_unqualified_access, 554 Weak and unowned references, 376 Weak references, 364 Where, 137 While, 126 While loops, 126 While statement, 477 Whitespace and comments, 420 Wildcard expression, 462 Wildcard pattern, 557 Working with characters, 87 607 TUNJAY AKBARLI MARYNA RYBALKO THE CODIRA PROGRAMMING LANGUAGE Submitted for collection: 17.05.2025 Print signed: 07.07.2025 Physical printed sheets: 32 ____________________________ Printed on SkyE Baku - 2025