Erica's proposal about "Modernizing Attribute Case and Attribute Argument Naming" made me remember this discussion.
I don't think a proposal was ever submitted? If no one else is working on a proposal already I would offer myself up for writing this up.
- Janosch
I don’t recall a real proposal, it would be great for you to drive this.
-Chris
On Feb 24, 2016, at 7:13 AM, Janosch Hildebrand via swift-evolution <swift-evolution@swift.org> wrote:
Erica's proposal about "Modernizing Attribute Case and Attribute Argument Naming" made me remember this discussion.
I don't think a proposal was ever submitted? If no one else is working on a proposal already I would offer myself up for writing this up.
Yes, please! I *really* want this change.
on Wed Feb 24 2016, Chris Lattner <swift-evolution@swift.org> wrote:
On Feb 24, 2016, at 7:13 AM, Janosch Hildebrand via swift-evolution <swift-evolution@swift.org> wrote:
Erica's proposal about "Modernizing Attribute Case and Attribute Argument Naming" made me remember this discussion.
I don't think a proposal was ever submitted? If no one else is
working on a proposal already I would offer myself up for writing
this up.I don’t recall a real proposal, it would be great for you to drive this.
--
-Dave
Same!
The only thing that needs to be considered is what to name the replacement attribute (for methods where the return value isn’t important). I’m thinking @optionalReturn or @ignoreUnusedResult or such.
On 24 Feb 2016, at 19:27, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
on Wed Feb 24 2016, Chris Lattner <swift-evolution@swift.org> wrote:
On Feb 24, 2016, at 7:13 AM, Janosch Hildebrand via swift-evolution <swift-evolution@swift.org> wrote:
Erica's proposal about "Modernizing Attribute Case and Attribute Argument Naming" made me remember this discussion.
I don't think a proposal was ever submitted? If no one else is
working on a proposal already I would offer myself up for writing
this up.I don’t recall a real proposal, it would be great for you to drive this.
Yes, please! I *really* want this change.
IMHO, before any decision, it may be interesting to write a quick patch and run the modified compiler on real code to see how much false positive it would generate.
Le 24 févr. 2016 à 16:13, Janosch Hildebrand via swift-evolution <swift-evolution@swift.org> a écrit :
Erica's proposal about "Modernizing Attribute Case and Attribute Argument Naming" made me remember this discussion.
I don't think a proposal was ever submitted? If no one else is working on a proposal already I would offer myself up for writing this up.
- Janosch
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
@discardableResult?
l8r
Sean
On Feb 24, 2016, at 2:37 PM, Haravikk via swift-evolution <swift-evolution@swift.org> wrote:
On 24 Feb 2016, at 19:27, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
on Wed Feb 24 2016, Chris Lattner <swift-evolution@swift.org> wrote:
On Feb 24, 2016, at 7:13 AM, Janosch Hildebrand via swift-evolution <swift-evolution@swift.org> wrote:
Erica's proposal about "Modernizing Attribute Case and Attribute Argument Naming" made me remember this discussion.
I don't think a proposal was ever submitted? If no one else is
working on a proposal already I would offer myself up for writing
this up.I don’t recall a real proposal, it would be great for you to drive this.
Yes, please! I *really* want this change.
Same!
The only thing that needs to be considered is what to name the replacement attribute (for methods where the return value isn’t important). I’m thinking @optionalReturn or @ignoreUnusedResult or such.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
Oh yes please, don't rush on this...
Who do we want to help here? API users, or API developers?
Considering that Swift may be on the verge of a great breakthrough, plenty of immature yet popular libraries will ship. Plenty have already shipped. This is a great sign of vitality. Should @warn_unused_result become the default, the quality of the code of the users of those libraries risks a brutal degradation, full of poor `let _ = ...`.
Gwendal
Le 24 févr. 2016 à 16:01, Jean-Daniel Dupas via swift-evolution <swift-evolution@swift.org> a écrit :
IMHO, before any decision, it may be interesting to write a quick patch and run the modified compiler on real code to see how much false positive it would generate.
Le 24 févr. 2016 à 16:13, Janosch Hildebrand via swift-evolution <swift-evolution@swift.org> a écrit :
Erica's proposal about "Modernizing Attribute Case and Attribute Argument Naming" made me remember this discussion.
I don't think a proposal was ever submitted? If no one else is working on a proposal already I would offer myself up for writing this up.
- Janosch
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
What about @warnUnusedResult being implied for @pure functions, and leaving it off by default for everything else?
- Dave Sweeris
On Feb 24, 2016, at 16:47, Gwendal Roué via swift-evolution <swift-evolution@swift.org> wrote:
Should @warn_unused_result become the default, the quality of the code of the users of those libraries risks a brutal degradation, full of poor `let _ = ...`.
Thanks for the encouragement everyone! I’ll start drafting over the weekend.
With regard to the inverted attribute, that is definitely open to discussion.
Other variants that had been mentioned previously include:
@suppress_unused_result - suggested by Adrian Kashivskyy
@allow_unused_result - suggested by Kevin Ballard
@ignoreresult - suggested by Brent Royal-Gordon
Also the aforementioned “Modernizing Attribute Case and Attribute Argument Naming” proposal[1] will also play into this discussion as well.
[1] [swift-evolution] [Discussion] Modernizing Attribute Case and Attribute Argument Naming
- Janosch
On 24 Feb 2016, at 21:37, Haravikk via swift-evolution <swift-evolution@swift.org> wrote:
On 24 Feb 2016, at 19:27, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
on Wed Feb 24 2016, Chris Lattner <swift-evolution@swift.org> wrote:
On Feb 24, 2016, at 7:13 AM, Janosch Hildebrand via swift-evolution <swift-evolution@swift.org> wrote:
Erica's proposal about "Modernizing Attribute Case and Attribute Argument Naming" made me remember this discussion.
I don't think a proposal was ever submitted? If no one else is
working on a proposal already I would offer myself up for writing
this up.I don’t recall a real proposal, it would be great for you to drive this.
Yes, please! I *really* want this change.
Same!
The only thing that needs to be considered is what to name the replacement attribute (for methods where the return value isn’t important). I’m thinking @optionalReturn or @ignoreUnusedResult or such.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
No worries, there should be plenty of time for discussion.
Swift 3 contains many changes that will require libraries to be updated anyway, so I don’t think this would prove to be an undue burden.
But yes, weighing cost vs. benefit will certainly be part of the proposal evaluation.
As for whom we want to help, it’s predominantly API users.
Ideally every function would be perfectly annotated but ultimately not every API developer will know about, remember or put in the effort to annotate with @warn_unused_result. Making the inverse the default should hopefully be “safer” by warning by default.
Extraneous warnings are also much more obvious than missing warnings, encouraging potential annotation.
The expectation that many if not most functions (with return values) should warn is, I believe, mostly motivating in the sense of hopefully making this change (more) palatable.
- Janosch
On 24 Feb 2016, at 23:47, Gwendal Roué <gwendal.roue@gmail.com> wrote:
Oh yes please, don't rush on this...
Who do we want to help here? API users, or API developers?
Considering that Swift may be on the verge of a great breakthrough, plenty of immature yet popular libraries will ship. Plenty have already shipped. This is a great sign of vitality. Should @warn_unused_result become the default, the quality of the code of the users of those libraries risks a brutal degradation, full of poor `let _ = ...`.
Gwendal
Le 24 févr. 2016 à 16:01, Jean-Daniel Dupas via swift-evolution <swift-evolution@swift.org> a écrit :
IMHO, before any decision, it may be interesting to write a quick patch and run the modified compiler on real code to see how much false positive it would generate.
Le 24 févr. 2016 à 16:13, Janosch Hildebrand via swift-evolution <swift-evolution@swift.org> a écrit :
Erica's proposal about "Modernizing Attribute Case and Attribute Argument Naming" made me remember this discussion.
I don't think a proposal was ever submitted? If no one else is working on a proposal already I would offer myself up for writing this up.
- Janosch
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
What about @warnUnusedResult being implied for @pure functions, and leaving it off by default for everything else?
I think this is the right way.
Ignoring the result of a call to a pure function is suspicious and most likely an error — but anything else is imho just dry-nursing developers:
As library author, I have to assume that clients have an idea of what they are doing; when someone uses my methods without knowing basic stuff like relevance of the return value, I can't enlighten him with with a warning that is nothing but annoyance for those who know what they are doing.
A monstrosity like "dont_warn_unused_result" would more or less discourage things like chaining, and the language imho shouldn't push you into that direction.
Of course, the status quo isn't good either, as @warn_unused_result is a ugly burden for those who want to give hints in their libraries…
I like Brents idea of putting the annotation next to the return type to indicate its effect, but prefer a variant:
mutating func nearlyPureMethod() @vital -> Type
(although I see dangers with this approach: "const" in C++ for example is imho quite confusing because its meaning depends on its position)
Something like
@void func canIgnoreResult(input: String) -> String
would be concise, but just because it looks familiar to many developes, it could be confusing as well.
A first thought was
func canIgnoreResult(input: String) -> Void|String
but on a second glance, I would rather expect such a return type to behave like String?
Tino
In this case, both. It's too easy to leave off an @warn_unused_result
and thereby fail to help your users.
on Wed Feb 24 2016, Gwendal Roué <swift-evolution@swift.org> wrote:
Oh yes please, don't rush on this...
Who do we want to help here? API users, or API developers?
--
-Dave
I'd recommend against snake case. (It's a thing). Some thoughts:
@SuppressResultUseWarning
@SuppressResultUsageWarning
@SuppressUnusedResultWarning
@OptionalResultUse (or Usage)
@PermitOptionalResultUse (or Usage)
@AllowOptionalResultUse (or Usage)
@IgnoreUnusedResult
@PermitUnusedResult
@AllowUnusedResult
@NoWarnUnusedResult
@NoResultWarning
@NoResultUseWarning
@NoResultUsageWarning
@NoWarningUnusedResult
@NoWarningForUnusedResult
@NoWarningOnUnusedResult
@AllowProceduralCall
@EnableProceduralCall
@PermitProceduralCall
-- E
On Feb 24, 2016, at 5:08 PM, Haravikk via swift-evolution <swift-evolution@swift.org> wrote:
On 24 Feb 2016, at 23:44, Janosch Hildebrand <jnosh@jnosh.com <mailto:jnosh@jnosh.com>> wrote:
Thanks for the encouragement everyone! I’ll start drafting over the weekend.
With regard to the inverted attribute, that is definitely open to discussion.
Other variants that had been mentioned previously include:@suppress_unused_result - suggested by Adrian Kashivskyy
@allow_unused_result - suggested by Kevin Ballard
@ignoreresult - suggested by Brent Royal-GordonAlso the aforementioned “Modernizing Attribute Case and Attribute Argument Naming” proposal[1] will also play into this discussion as well.
[1] [swift-evolution] [Discussion] Modernizing Attribute Case and Attribute Argument Naming
- Janosch
While I like the brevity, I don’t think @ignoreresult is clear enough on what it does, @optional_result (or ideally @optionalResult if camel-case for attributes is accepted) is clearer I think if we want a shortened two-word form. Or there’s Sean’s @discardable_result alternative which is even clearer.
Otherwise @allow_unused_result is the best of the three word options I think; @suppress_unused_result is a bit unclear as what you’re actually suppressing is the compiler warning, as in most cases a result will still be generated, it’s just not stored anywhere at the call site.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
@optional_result (or ideally @optionalResult if camel-case for attributes is accepted) is clearer I think if we want a shortened two-word form.
I don't like "optional" here because it falsely implies a connection with the Optional type.
I do think, however, that this needs to be something very short—one or two words, not three or four. One way to trim words would be to attach the attribute to the return type; the position would imply that the keyword related to the return type, so the word "result" would be unnecessary:
@ignoreUnusedResult mutating func removeLast() -> Element
mutating func removeLast() -> @ignoreUnused Element
That might be a little strange, though—we don't currently have any attributes in that position.
Another way to make this shorter is to try to find an adjective which implies *why* we can ignore the result—that is, because it isn't important. The problem is that most such adjectives are either compound words:
@unimportantResult mutating func removeLast() -> Element
mutating func removeLast() -> @unimportant Element
@discardableResult mutating func removeLast() -> Element
mutating func removeLast() -> @discardable Element
Or they're uncommon words people may need to look up:
@banalResult mutating func removeLast() -> Element
mutating func removeLast() -> @banal Element
Actually, I can think of one word in the latter category that many programmers *do* know:
@trivialResult mutating func removeLast() -> Element
mutating func removeLast() -> @trivial Element
--
Brent Royal-Gordon
Architechies
I'd rather have something clear than short.
Some short ones that haven't been mentioned:
@Statement has a problem because the result can be used, it's just not mandated.
@Statementable just makes no English sense at all (similarly @Procedurable) but kind of communicates the idea
@ResultDiscardable: not a fan
@StatementAllowed or @AllowStatement really doesn't make a ton of sense, but it's short and kind of gets the point across.
@SideEffects also short, also kind hints at stuff, also could be misleading, and the same for @HasSideEffects.
My favorite remains @SuppressUnusedResultWarning, which isn't short but pretty damn clear.
On Feb 24, 2016, at 7:32 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:
@optional_result (or ideally @optionalResult if camel-case for attributes is accepted) is clearer I think if we want a shortened two-word form.
No worries, there should be plenty of time for discussion.
Swift 3 contains many changes that will require libraries to be updated anyway, so I don’t think this would prove to be an undue burden.
Agreed - source breaking changes in Swift 3 are already a given, so we’re going to provide a really great migrator to help move people forward. Beyond Swift 3, the Swift community will be a much more diverse place with multiple platforms supported and more diverse tools/ide’s used.
As such, source breaking changes will be much more difficult to justify after Swift 3 is out the door, we’re prefer to roll them into Swift 3 where ever possible.
-Chris
On Feb 24, 2016, at 3:45 PM, Janosch Hildebrand via swift-evolution <swift-evolution@swift.org> wrote:
But yes, weighing cost vs. benefit will certainly be part of the proposal evaluation.
As for whom we want to help, it’s predominantly API users.
Ideally every function would be perfectly annotated but ultimately not every API developer will know about, remember or put in the effort to annotate with @warn_unused_result. Making the inverse the default should hopefully be “safer” by warning by default.Extraneous warnings are also much more obvious than missing warnings, encouraging potential annotation.
The expectation that many if not most functions (with return values) should warn is, I believe, mostly motivating in the sense of hopefully making this change (more) palatable.
- Janosch
On 24 Feb 2016, at 23:47, Gwendal Roué <gwendal.roue@gmail.com> wrote:
Oh yes please, don't rush on this...
Who do we want to help here? API users, or API developers?
Considering that Swift may be on the verge of a great breakthrough, plenty of immature yet popular libraries will ship. Plenty have already shipped. This is a great sign of vitality. Should @warn_unused_result become the default, the quality of the code of the users of those libraries risks a brutal degradation, full of poor `let _ = ...`.
Gwendal
Le 24 févr. 2016 à 16:01, Jean-Daniel Dupas via swift-evolution <swift-evolution@swift.org> a écrit :
IMHO, before any decision, it may be interesting to write a quick patch and run the modified compiler on real code to see how much false positive it would generate.
Le 24 févr. 2016 à 16:13, Janosch Hildebrand via swift-evolution <swift-evolution@swift.org> a écrit :
Erica's proposal about "Modernizing Attribute Case and Attribute Argument Naming" made me remember this discussion.
I don't think a proposal was ever submitted? If no one else is working on a proposal already I would offer myself up for writing this up.
- Janosch
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
I'd rather have something clear than short.
Some short ones that haven't been mentioned:
@Statement has a problem because the result can be used, it's just not mandated.
@Statementable just makes no English sense at all (similarly @Procedurable) but kind of communicates the idea
@ResultDiscardable: not a fan
@StatementAllowed or @AllowStatement really doesn't make a ton of sense, but it's short and kind of gets the point across.
@SideEffects also short, also kind hints at stuff, also could be misleading, and the same for @HasSideEffects.
My favorite remains @SuppressUnusedResultWarning, which isn't short but pretty damn clear.
+1. This would be my choice as well. It is the warning that is affected, not the result, so “Warning” or “NoWarn” should be in the name.
—CK
On Feb 24, 2016, at 7:12 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:
On Feb 24, 2016, at 7:32 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
@optional_result (or ideally @optionalResult if camel-case for attributes is accepted) is clearer I think if we want a shortened two-word form.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
These lack conciseness. What about the already supported:
let _ = ingoreResult()
Where ignoreResult is the function. Or maybe something even more brief? What was wrong with (void)? or
(_)ingoreResult()
- Paul
On Feb 24, 2016, at 8:42 PM, Charles Kissinger via swift-evolution <swift-evolution@swift.org> wrote:
On Feb 24, 2016, at 7:12 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
I'd rather have something clear than short.
Some short ones that haven't been mentioned:
@Statement has a problem because the result can be used, it's just not mandated.
@Statementable just makes no English sense at all (similarly @Procedurable) but kind of communicates the idea
@ResultDiscardable: not a fan
@StatementAllowed or @AllowStatement really doesn't make a ton of sense, but it's short and kind of gets the point across.
@SideEffects also short, also kind hints at stuff, also could be misleading, and the same for @HasSideEffects.
My favorite remains @SuppressUnusedResultWarning, which isn't short but pretty damn clear.+1. This would be my choice as well. It is the warning that is affected, not the result, so “Warning” or “NoWarn” should be in the name.
—CK
On Feb 24, 2016, at 7:32 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
@optional_result (or ideally @optionalResult if camel-case for attributes is accepted) is clearer I think if we want a shortened two-word form.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
These lack conciseness. What about the already supported:
let _ = ingoreResult()
I would be perfectly happy with requiring “let _ = “ myself. My recollection of the previous discussion is that most people didn’t want that to be necessary and preferred a suppressible warning.
Thinking about the attribute name some more, I might prefer:
@NoUnusedResultWarning
which is a variation of one of Erica’s suggestions. It is at least slightly shorter than @SuppressUnusedResultWarning
—CK
On Feb 24, 2016, at 9:19 PM, Paul Ossenbruggen <possen@gmail.com> wrote:
Where ignoreResult is the function. Or maybe something even more brief? What was wrong with (void)? or
(_)ingoreResult()
- Paul
On Feb 24, 2016, at 8:42 PM, Charles Kissinger via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Feb 24, 2016, at 7:12 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
I'd rather have something clear than short.
Some short ones that haven't been mentioned:
@Statement has a problem because the result can be used, it's just not mandated.
@Statementable just makes no English sense at all (similarly @Procedurable) but kind of communicates the idea
@ResultDiscardable: not a fan
@StatementAllowed or @AllowStatement really doesn't make a ton of sense, but it's short and kind of gets the point across.
@SideEffects also short, also kind hints at stuff, also could be misleading, and the same for @HasSideEffects.
My favorite remains @SuppressUnusedResultWarning, which isn't short but pretty damn clear.+1. This would be my choice as well. It is the warning that is affected, not the result, so “Warning” or “NoWarn” should be in the name.
—CK
On Feb 24, 2016, at 7:32 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
@optional_result (or ideally @optionalResult if camel-case for attributes is accepted) is clearer I think if we want a shortened two-word form.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
Since we don’t care about the result?
_ = ignoreResult()
It does not matter whether it is mutable or not so dropping the keyword is ok here. This is really obvious what it does and is concise.
On Feb 24, 2016, at 9:54 PM, Charles Kissinger <crk@akkyra.com> wrote:
On Feb 24, 2016, at 9:19 PM, Paul Ossenbruggen <possen@gmail.com <mailto:possen@gmail.com>> wrote:
These lack conciseness. What about the already supported:
let _ = ingoreResult()
I would be perfectly happy with requiring “let _ = “ myself. My recollection of the previous discussion is that most people didn’t want that to be necessary and preferred a suppressible warning.
Thinking about the attribute name some more, I might prefer:
@NoUnusedResultWarning
which is a variation of one of Erica’s suggestions. It is at least slightly shorter than @SuppressUnusedResultWarning
—CK
Where ignoreResult is the function. Or maybe something even more brief? What was wrong with (void)? or
(_)ingoreResult()
- Paul
On Feb 24, 2016, at 8:42 PM, Charles Kissinger via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Feb 24, 2016, at 7:12 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
I'd rather have something clear than short.
Some short ones that haven't been mentioned:
@Statement has a problem because the result can be used, it's just not mandated.
@Statementable just makes no English sense at all (similarly @Procedurable) but kind of communicates the idea
@ResultDiscardable: not a fan
@StatementAllowed or @AllowStatement really doesn't make a ton of sense, but it's short and kind of gets the point across.
@SideEffects also short, also kind hints at stuff, also could be misleading, and the same for @HasSideEffects.
My favorite remains @SuppressUnusedResultWarning, which isn't short but pretty damn clear.+1. This would be my choice as well. It is the warning that is affected, not the result, so “Warning” or “NoWarn” should be in the name.
—CK
On Feb 24, 2016, at 7:32 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
@optional_result (or ideally @optionalResult if camel-case for attributes is accepted) is clearer I think if we want a shortened two-word form.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution