You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Mar 26, 2023. It is now read-only.
[SE-0276](https://github.com/apple/swift-evolution/blob/master/proposals/0276-multi-pattern-catch-clauses.md): *Multi-Pattern Catch Clauses* was [accepted](https://forums.swift.org/t/accepted-se-0276-multi-pattern-catch-clauses/33220).
78
+
79
+
> Feedback was almost universally positive, and the proposal has been accepted!
80
+
Thank you to everyone who participated in the review process.
61
81
62
82
### Rejected proposals
63
83
64
-
> TODO
84
+
[SE-0275](https://github.com/apple/swift-evolution/blob/master/proposals/0275-allow-more-characters-like-whitespaces-and-punctuations-for-escaped-identifiers.md): *Allow more characters (like whitespaces and punctuations) for escaped identifiers* was [rejected](https://forums.swift.org/t/se-0275-allow-more-characters-like-whitespaces-and-punctuations-for-escaped-identifiers/32538/46).
85
+
86
+
> The core team has decided to reject this proposal. Community reaction was
87
+
mixed, and many of the people both supporting and rejecting the idea had
88
+
concerns about the breadth of the set of characters this allows. Allowing more
89
+
characters in identifiers would also add complexity to tooling, including
90
+
syntax highlighting, IDEs, and runtime reflection libraries, which would need
91
+
to be able to recognize quoted identifiers, know when identifiers would need
92
+
to be quoted for presentation purposes, and potentially need to implement more
93
+
elaborate parsing and escaping rules to handle these generalized identifiers.
94
+
In the core team's judgment, this added demand on tooling is not justified by
95
+
the amount of utility provided by the proposal.
65
96
66
97
### Proposals in review
67
98
99
+
[SE-0274](https://github.com/apple/swift-evolution/blob/master/proposals/0274-magic-file.md): *Concise magic file names* is [under a second review](https://forums.swift.org/t/re-review-se-0274-concise-magic-file-names/33171).
100
+
101
+
> The original review thread concluded with the core team accepting the
102
+
proposal in principal: `#file` will be updated to include only the file and
103
+
module names, with `#filePath` introduced for use cases that require the full
104
+
path to the file.
105
+
>
106
+
> However, during the review it was proposed that the exact format of `#file`
107
+
be specified, in order to allow for future tooling to rely on that format to
108
+
determine the file and module name from the string.
109
+
>
110
+
> The proposal has been amended to explicitly include this format, and this
111
+
re-review is focused on that aspect of the proposal.
112
+
113
+
> **Changes since the first review**
114
+
>
115
+
> - We now specify that the `#file` string will have the format
116
+
`<module-name>/<file-name>` (with a second form for future expansion) and
117
+
discuss how to parse it. The previous revision left this format as a compiler
118
+
implementation detail that tools should always treat as opaque.
119
+
> - We now discuss the behavior of `#sourceLocation`'s `file` parameter and
120
+
provide for a warning when it creates conflicts. The previous revision did not
121
+
discuss these topics.
122
+
> - We now mention the need for tooling to map `#file` strings back to paths.
123
+
> - We now provide for a warning when a wrapper around a `#filePath`-defaulting
124
+
function passes it `#file` instead, or vice versa. The previous revision did
125
+
not discuss this.
126
+
> - We have added several suggestions from the first review to the
127
+
"alternatives considered" section to explain why we aren't proposing them.
128
+
68
129
[SE-0270](https://github.com/apple/swift-evolution/blob/master/proposals/0270-rangeset-and-collection-operations.md): *Add Collection Operations on Noncontiguous Elements* is [under a third review](https://forums.swift.org/t/se-0270-review-3-add-collection-operations-on-noncontiguous-elements/32839).
69
130
70
131
> We can use a `Range<Index>` to refer to a group of consecutive positions in a
@@ -135,6 +196,97 @@ f(.zero.incremented) // Error: Cannot infer contextual base in reference to memb
to add Localized Resources to the Swift Package Manager.
248
+
249
+
> This proposal builds on top of the [Package Manager Resources](https://github.com/apple/swift-evolution/blob/master/proposals/0271-package-manager-resources.md)
250
+
proposal to allow defining localized versions of resources in the SwiftPM
251
+
manifest and have them automatically accessible at runtime using the same APIs.
0 commit comments