A lot of proposals have been evaluated over the last couple of weeks since the “Big 3” acceptance. Here’s a quick wrap-up of what’s been accepted and deferred, and what’s currently under review.

Newly accepted proposals:

SE-0046 Establish consistent label behavior across all parameters including first labels normalizes the first parameter declaration in methods and functions. First parameter declarations will now match the existing behavior of the second and later parameters. All parameters, regardless of position, will behave uniformly. This will create a simple, consistent approach to parameter declaration throughout the Swift programming language and bring method and function declarations in-sync with initializers, which already use this standard.

Because of this proposal, the need to “double up” first parameter names to expose them as external labels is gone. To hide the parameter label, use the same “_ ” (underscore followed by space) approach as you do with second and later parameters.

SE-0037 Clarify interaction between comments & operators fixes inconsistencies in how comments are treated when determining whether an operator is prefix, postfix, or infix. They are sometimes treated as whitespace, sometimes as non-whitespace, and this differs depending on whether they are to the left or right of an operator, and the contents of the comment itself. This proposal introduced a uniform set of rules for how these cases should be parsed.

SE-0040 Replacing Equal Signs with Colons For Attribute Arguments . (Thanks Daniel Duan for implementation) Attribute arguments are unlike other Swift language arguments. At the call site, they use = instead of colons to distinguish argument names from passed values. This proposal brings attributes into compliance with Swift standard practices by replacing the use of “=” with “:” in this one-off case.

SE-0039 Modernizing Playground Literals Playground literals tokenize colors, files, and images. They provide drag-and-drop convenience and in-context visualizations that offer easy reference and manipulation when designing playground content. These literals are built using a simple square bracket syntax that, in the current form, conflicts with collection literalsThis proposal redesigns playground literals to follow the precedent of #available and #selector.

SE-0033 Import Objective-C Constants as Swift Types Given a list of constants in an Objective-C file, add an attribute that will enable Swift to import them as either an Enum or a Struct, using RawRepresentable to convert to their original type. Instead of passing strings around for APIs, the proposal introduces type-safe objects to take advantage of Swift’s code completion. This proposal should make Swift (and Objective-C!) code more readable and more approachable to beginners.

Deferred

Active Review

SE-0044 Import as Member review runs until 3/22. This proposal seeks to provide a mechanism for C API authors to specify the capability of importing functions and variables as members on imported Swift types. It also seeks to provide an automatic inference option for APIs that follow a consistent, disciplined naming convention.

Michael Ilseman writes,

There’s two things present in this proposal, manual annotation and automatic inference. Projects such as sqlite3 can use manual annotation, so that they can control their APIs and have a chance to import e.g. sqlite3_stmt_readonly as a member on a type (perhaps also named/defined otherwise, e.g. through existing attributes or other proposed elsewhere).

Automatic inference, at least in the near term, will not be turned on by default for all C APIs, but will start out as opt-in. In the near term, heuristics and techniques are tuned for CF-style naming conventions…Future work could expand the inference system to have many more (configurable) heuristics, but that’s out of scope for this proposal. But, unless the project opts-in, the inference system will not try to infer how to import as a member.