Re: [swift-evolution] Proposal: Add .times method to Integer type

[Howard Lovatt via swift-evolution]

+1 to 5.times{stuff} from me. I much prefer library functions to language
extensions.

  -- Howard.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Proposal: Add .times method to Integer type

[T.J. Usiyan via swift-evolution]

-1 from me. It is simple enough for an extension and provides little
benefit as a standard library inclusion.

On Sun, Dec 20, 2015 at 9:10 PM, Howard Lovatt via swift-evolution <
swift-evolution@swift.org> wrote:

> +1 to 5.times{stuff} from me. I much prefer library functions to language
> extensions.
>
>   -- Howard.
>
> ___
> 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

Re: [swift-evolution] Proposal: Add .times method to Integer type

[Félix Cloutier via swift-evolution]

The Foundation  framework 
is being ported to other platforms and it has CGSize and NSDate (but not 
NSImage/UIImage). For the rest, the Swift package manager 
 will probably fulfill that 
role, no?

> Le 20 déc. 2015 à 06:09:19, Tino Heth via swift-evolution 
>  a écrit :
> 
> I guess everyone agrees that it is easy to add the functionality with an 
> extension — and I'm quite sure many will do so.
> For me, the need to add the method on my own (if I want to use it) is not an 
> issue, but imho having several thousand implementations of the same concept 
> isn't that appealing.
> Tiny methods like "times" should be inlined anyways, so it actually doesn't 
> matter, but for types and bigger functions, standardization would be a good 
> thing:
> C++ for example might have seen many thousand incompatible implementations of 
> basic concepts like "point", "vector", "either" or "picture", most of them 
> nearly identical and only created because there was nothing to build on.
> It is a bad idea to put every possible concept into the standard lib, which 
> imho should be as small and compact as possible, but looking at C++ again, 
> there is boost…
> 
> So for me it would make sense to have a set of "semi"-standard libs to ensure 
> that there is some consensus on common datatypes (especially protocols).
> Right now, the Cocoa libs help us with things like CGSize, NSDate and 
> UIImage, but I think this fundament is not the best choice for Swift on other 
> platforms.
> 
> How about proposing to start adding some more official git-repositories for 
> libs? That would be a much bigger thing than adding "Int.times", but as with 
> boost, it could easily evolve alongside core Swift.
> 
> Tino
> ___
> 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

Re: [swift-evolution] Proposal: Add .times method to Integer type

[Andrew Hoos via swift-evolution]

Summary of feedback

Cons
Block based API prevents return/break/continue
Can be implemented by an extension without language changes
Vaguely confusable with multiplication

Pros
Is easier for new learners
Removes ambiguity of ..< vs ... (again mostly new learners)
shorter than existing syntax

Alternatives
for _ in 0..< 5_000 (current solution)
repeat 5_000 (alternative syntax)
for 5_000

My $.02

If we are going to introduce a new "something" it should either provide a 
feature that is currently impossible or it should provide a significantly 
better way to do something that can already be done. With that as my metric I 
find 5_000.times to be moderately better at best and does not meet my standard 
for inclusion.

Andrew Hoos


> On Dec 19, 2015, at 16:35, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>> I do have an honest question that comes from ignorance rather than malice: 
>> has anyone actually used .times in ruby outside of the context of learning 
>> or testing?
> 
> I've seen it used to retry a failing operation a certain number of times:
> 
>   5.times do
>   return true if do_network_call
>   sleep 5
>   end
>   raise NetworkCallFailedError
> 
> Of course, that requires you to be able to return out of the surrounding 
> function from the `times` loop, which you can do in Ruby but not in Swift.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> 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

Re: [swift-evolution] Proposal: Add .times method to Integer type

[Brent Royal-Gordon via swift-evolution]

> I do have an honest question that comes from ignorance rather than malice: 
> has anyone actually used .times in ruby outside of the context of learning or 
> testing?

I've seen it used to retry a failing operation a certain number of times:

5.times do
return true if do_network_call
sleep 5
end
raise NetworkCallFailedError

Of course, that requires you to be able to return out of the surrounding 
function from the `times` loop, which you can do in Ruby but not in Swift.

-- 
Brent Royal-Gordon
Architechies

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Proposal: Add .times method to Integer type

[Dave Abrahams via swift-evolution]

-1 from me, if nothing else because the name is confusable with multiplication 
in the context of integers.

> On Dec 18, 2015, at 11:53 AM, Jacob Bandes-Storch via swift-evolution 
>  wrote:
> 
> I like how clean "100.times { doSomething() }" looks, but I'm concerned its 
> usefulness will be limited because control-flow statements like 
> break/continue/return won't work from inside a closure.
> 
> Jacob
> 
> On Fri, Dec 18, 2015 at 11:36 AM, Cihat Gündüz  > wrote:
> 
>> Am 18.12.2015 um 20:13 schrieb Félix Cloutier > >:
>> 
>> It doesn't need to be an underscore, but when it is not, the compiler emits 
>> an educative warning steering you towards _:
> 
> It’s not about the underscore as a character, it’s about the fact that there 
> is the clutter of an underscore at all what I don’t like and what makes me 
> feel the code isn’t as clean as it could be.
> 
>> 
>> /tmp/test.swift:3:7: warning: immutable value 'i' was never used; consider 
>> replacing with '_' or removing it
>> 
>> You can also use inclusive ranges instead if you're more comfortable with 
>> that: 1...5000 will do just that.
> 
> I’m comfortable with ranges but I also used to teach Java back a few years 
> ago and I saw computer science students struggle with the exact number a loop 
> was being executed. So that’s the only reason I brought up that example to 
> have an additional argument.
> 
> But again, for me it is more about the clutter that the 1… or 0..< adds to 
> something that could so easily made simpler and more descriptive.
> 
> I think this is also a question of: How many convenience methods do we want 
> to see in the Swift standard library? In Ruby, at least, there seemed to be 
> enough people to find this one useful. And it’s the first method I missed 
> until now, so I took that as a sign before suggesting the addition. I also 
> don’t like when there are thousands of convenience methods for things that 
> could easily be written in other ways – but I don’t feel that way with the 
> suggested .times method.
> 
>> 
>> I don't mean to come across as dismissive, and I'm all for an inclusive 
>> Swift that you can pick up without knowing advanced concepts. However, there 
>> is definitely value in helping people learn, and learning always moves you a 
>> little bit out of your comfort zone. When do we remove the training wheels? 
>> How long can we hide the fact that indices usually start at 0? How long 
>> before you need to iterate an array using the same range-based for loop?
>> 
>> I spend a lot of time on Stack Overflow and I've seen lots of beginners ask 
>> for lots of things, but the people who ask about the for loop are usually 
>> people with a background in another C-like language who try to use the 
>> arguably less readable C-like for loop. I've never seen anyone before say 
>> that it looks unclean or unreadable.
> 
> I understand what you mean but I don’t think that this is about indices or 
> beginners. The fact that readability and expressiveness make a language 
> easier to learn for beginners IMHO is just a side effect of a well 
> thought-out and developed language. Maybe I wasn’t clear enough but I want to 
> see the .times method in Swift for my own usage, not for beginners. :)
> 
>> 
>>> Le 18 déc. 2015 à 13:38:59, Cihat Gündüz via swift-evolution 
>>> > a écrit :
>>> 
>>> I agree with both of you about the alternative implementations.
>>> 
>>> That’s exactly what I’d love to see integrated to the standard library like 
>>> Ruby is here:
>>> http://ruby-doc.org/core-2.2.4/Integer.html#method-i-times 
>>> 
>>> 
>>> My main problem is that it neither looks clean nor readable especially for 
>>> beginners that there is an underscore in the closure. Also beginners often 
>>> get confused with the number of times some code is run when starting to 
>>> count from 0 which is also why I think it shouldn’t appear. The .times 
>>> method would solve both of these problems.
>>> 
 Am 18.12.2015 um 19:33 schrieb Etan Kissling >:
 
 (or with a for in loop  -- but i guess you have a reason for using 
 .foreach)
 
 for _ in 0..<5_000 {
 print("asdf")
 }
 
 
> On 18 Dec 2015, at 19:31, Etan Kissling via swift-evolution 
> > wrote:
> 
> You don't need stride for this.
> 
> func foo() {
> (0..<5_000).forEach { _ in
> print("asdf")
> }
> }
> 
> 
>> On 18 Dec 2015, at 19:25, Cihat Gündüz via swift-evolution 
>> > wrote:
>> 
>> 

Re: [swift-evolution] Proposal: Add .times method to Integer type

[Etan Kissling via swift-evolution]

You don't need stride for this.

func foo() {
(0..<5_000).forEach { _ in
print("asdf")
}
}


On 18 Dec 2015, at 19:25, Cihat Gündüz via swift-evolution 
> wrote:

Dear Swift-Community,

I’d like to propose an addition of a useful method, especially for beginners 
that also makes Swift much more readable in some situations: The addition of a 
.times method to Integer type(s).

For example recently in one of my projects I wanted to test the scalability of 
an important piece of code and wrote this method:

func testPerfQualityInPercentWithoutQualityImprovements() {
self.measureBlock {
let expectedQuality = 33.33
0.stride(to: 5_000, by: 1).forEach { _ in
XCTAssertEqualWithAccuracy(self.crossword.qualityInPercent, 
expectedQuality, accuracy: 0.1)
}
}
}

As you can see what I basically wanted was to repeat the test some thousand 
times. I also like to use the Ruby language and one thing I love about it is 
that it has some really handy methods integrated to the language in situations 
like this which make the code very readable and therefore fun to use.

I’m an even bigger fan of Swift so I’d love to see such useful methods appear 
in Swift, too and this is the first I came across that I really missed. So I’m 
asking myself, what if I could write the same code above like this:

func testPerfQualityInPercentWithoutQualityImprovements() {
self.measureBlock {
let expectedQuality = 33.33
5_000.times {
XCTAssertEqualWithAccuracy(self.crossword.qualityInPercent, 
expectedQuality, accuracy: 0.1)
}
}
}

I think it could be added to the Swift standard library very easily (for 
example by using the .stride method like I used) without any side effects and 
has enough advantages to be part of Swift itself. What do you think?

I wish you all the best,
Cihat


P.S.: This is my very first mail in such a mailing list so I did everything 
correctly. ^.^


___
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

Re: [swift-evolution] Proposal: Add .times method to Integer type

[Cihat Gündüz via swift-evolution]

> Am 18.12.2015 um 21:02 schrieb Dave Abrahams :
> 
> -1 from me, if nothing else because the name is confusable with 
> multiplication in the context of integers.

Isn’t it a multiplication? A multiplication of the closure specified? I see it 
as such.

Also I don’t think many will confuse a method that takes a closure with the 
multiplication of two integers. I may be wrong, of course.

– Cihat

> 
>> On Dec 18, 2015, at 11:53 AM, Jacob Bandes-Storch via swift-evolution 
>> > wrote:
>> 
>> I like how clean "100.times { doSomething() }" looks, but I'm concerned its 
>> usefulness will be limited because control-flow statements like 
>> break/continue/return won't work from inside a closure.
>> 
>> Jacob
>> 
>> On Fri, Dec 18, 2015 at 11:36 AM, Cihat Gündüz > > wrote:
>> 
>>> Am 18.12.2015 um 20:13 schrieb Félix Cloutier >> >:
>>> 
>>> It doesn't need to be an underscore, but when it is not, the compiler emits 
>>> an educative warning steering you towards _:
>> 
>> It’s not about the underscore as a character, it’s about the fact that there 
>> is the clutter of an underscore at all what I don’t like and what makes me 
>> feel the code isn’t as clean as it could be.
>> 
>>> 
>>> /tmp/test.swift:3:7: warning: immutable value 'i' was never used; consider 
>>> replacing with '_' or removing it
>>> 
>>> You can also use inclusive ranges instead if you're more comfortable with 
>>> that: 1...5000 will do just that.
>> 
>> I’m comfortable with ranges but I also used to teach Java back a few years 
>> ago and I saw computer science students struggle with the exact number a 
>> loop was being executed. So that’s the only reason I brought up that example 
>> to have an additional argument.
>> 
>> But again, for me it is more about the clutter that the 1… or 0..< adds to 
>> something that could so easily made simpler and more descriptive.
>> 
>> I think this is also a question of: How many convenience methods do we want 
>> to see in the Swift standard library? In Ruby, at least, there seemed to be 
>> enough people to find this one useful. And it’s the first method I missed 
>> until now, so I took that as a sign before suggesting the addition. I also 
>> don’t like when there are thousands of convenience methods for things that 
>> could easily be written in other ways – but I don’t feel that way with the 
>> suggested .times method.
>> 
>>> 
>>> I don't mean to come across as dismissive, and I'm all for an inclusive 
>>> Swift that you can pick up without knowing advanced concepts. However, 
>>> there is definitely value in helping people learn, and learning always 
>>> moves you a little bit out of your comfort zone. When do we remove the 
>>> training wheels? How long can we hide the fact that indices usually start 
>>> at 0? How long before you need to iterate an array using the same 
>>> range-based for loop?
>>> 
>>> I spend a lot of time on Stack Overflow and I've seen lots of beginners ask 
>>> for lots of things, but the people who ask about the for loop are usually 
>>> people with a background in another C-like language who try to use the 
>>> arguably less readable C-like for loop. I've never seen anyone before say 
>>> that it looks unclean or unreadable.
>> 
>> I understand what you mean but I don’t think that this is about indices or 
>> beginners. The fact that readability and expressiveness make a language 
>> easier to learn for beginners IMHO is just a side effect of a well 
>> thought-out and developed language. Maybe I wasn’t clear enough but I want 
>> to see the .times method in Swift for my own usage, not for beginners. :)
>> 
>>> 
 Le 18 déc. 2015 à 13:38:59, Cihat Gündüz via swift-evolution 
 > a écrit :
 
 I agree with both of you about the alternative implementations.
 
 That’s exactly what I’d love to see integrated to the standard library 
 like Ruby is here:
 http://ruby-doc.org/core-2.2.4/Integer.html#method-i-times 
 
 
 My main problem is that it neither looks clean nor readable especially for 
 beginners that there is an underscore in the closure. Also beginners often 
 get confused with the number of times some code is run when starting to 
 count from 0 which is also why I think it shouldn’t appear. The .times 
 method would solve both of these problems.
 
> Am 18.12.2015 um 19:33 schrieb Etan Kissling  >:
> 
> (or with a for in loop  -- but i guess you have a reason for using 
> .foreach)
> 
> for _ in 0..<5_000 {
> print("asdf")
> }
> 
> 
>> On 18 Dec 2015, at 19:31, Etan 

Re: [swift-evolution] Proposal: Add .times method to Integer type

[Radosław Pietruszewski via swift-evolution]

> But isn’t that more a sign that Swift needs a way to make closures more 
> useful by adding the possibility of breaking/continueing/returning from 
> within them rather than a disadvantage of the `times`-syntax itself?

Perhaps — there’s a thread, somewhere, with possible solutions to this.

FWIW, I’m just as concerned about allowing returning/etc in closures, as with 
the lack of this ability. Ruby has different forms of “closures”, far too many 
of them actually, and some of them truly act like functions (just like in 
Swift), and in some, return/etc changes the calling function. And… albeit 
useful… this can be _really_ confusing.

> Do you think `times` wouldn’t be useful enough with the closure restriction?

I’d still like it, but it’s just this tiny little thing. Swift standard library 
is currently very bare-bones, unlike, say, Ruby’s, which has *a ton* of stuff 
on Arrays, Strings, etc. Unless the Core Team is OK with expanding those 
standard types with more useful helper methods more broadly, there’s no reason 
why `times` in particular should go in.

/ccing Chris on this question.

— Radek

> On 18 Dec 2015, at 21:09, Cihat Gündüz via swift-evolution 
>  wrote:
> 
> @Jacob, @Radek: Seems like you’ve found a clear restriction to the methods 
> usefulness given a simple implementation. You are right, of course. But isn’t 
> that more a sign that Swift needs a way to make closures more useful by 
> adding the possibility of breaking/continueing/returning from within them 
> rather than a disadvantage of the `times`-syntax itself?
> 
> I mean, I find the closure-solution useful already. But if 
> break/continue/return would work from within the curly braces somehow (either 
> by a non-closure-based implementation like for-in loops or via a future 
> addition of some kind of strong/weak return etc.) then I agree that it would 
> be even more useful.
> 
> Do you think `times` wouldn’t be useful enough with the closure restriction?
> 
> 
>> Am 18.12.2015 um 20:53 schrieb Jacob Bandes-Storch > >:
>> 
>> I like how clean "100.times { doSomething() }" looks, but I'm concerned its 
>> usefulness will be limited because control-flow statements like 
>> break/continue/return won't work from inside a closure.
>> 
>> Jacob
>> 
>> On Fri, Dec 18, 2015 at 11:36 AM, Cihat Gündüz > > wrote:
>> 
>>> Am 18.12.2015 um 20:13 schrieb Félix Cloutier >> >:
>>> 
>>> It doesn't need to be an underscore, but when it is not, the compiler emits 
>>> an educative warning steering you towards _:
>> 
>> It’s not about the underscore as a character, it’s about the fact that there 
>> is the clutter of an underscore at all what I don’t like and what makes me 
>> feel the code isn’t as clean as it could be.
>> 
>>> 
>>> /tmp/test.swift:3:7: warning: immutable value 'i' was never used; consider 
>>> replacing with '_' or removing it
>>> 
>>> You can also use inclusive ranges instead if you're more comfortable with 
>>> that: 1...5000 will do just that.
>> 
>> I’m comfortable with ranges but I also used to teach Java back a few years 
>> ago and I saw computer science students struggle with the exact number a 
>> loop was being executed. So that’s the only reason I brought up that example 
>> to have an additional argument.
>> 
>> But again, for me it is more about the clutter that the 1… or 0..< adds to 
>> something that could so easily made simpler and more descriptive.
>> 
>> I think this is also a question of: How many convenience methods do we want 
>> to see in the Swift standard library? In Ruby, at least, there seemed to be 
>> enough people to find this one useful. And it’s the first method I missed 
>> until now, so I took that as a sign before suggesting the addition. I also 
>> don’t like when there are thousands of convenience methods for things that 
>> could easily be written in other ways – but I don’t feel that way with the 
>> suggested .times method.
>> 
>>> 
>>> I don't mean to come across as dismissive, and I'm all for an inclusive 
>>> Swift that you can pick up without knowing advanced concepts. However, 
>>> there is definitely value in helping people learn, and learning always 
>>> moves you a little bit out of your comfort zone. When do we remove the 
>>> training wheels? How long can we hide the fact that indices usually start 
>>> at 0? How long before you need to iterate an array using the same 
>>> range-based for loop?
>>> 
>>> I spend a lot of time on Stack Overflow and I've seen lots of beginners ask 
>>> for lots of things, but the people who ask about the for loop are usually 
>>> people with a background in another C-like language who try to use the 
>>> arguably less readable C-like for loop. I've never seen anyone before say 
>>> that it looks unclean or unreadable.
>> 
>> I understand what you mean but I 

Re: [swift-evolution] Proposal: Add .times method to Integer type

[Chris Lattner via swift-evolution]

> On Dec 18, 2015, at 12:32 PM, Radosław Pietruszewski  
> wrote:
> 
>> 
>> My personal opinion on this is that 5.times { stuff} offers no benefits over 
>> “repeat 5 { stuff }”, so I’d rather see the later (if anything).
>> 
>> This is all shades of gray with no clear answer.  We generally want to have 
>> standard APIs pay for themselves and avoid confusion.  I agree with DaveA’s 
>> points upthread.  If you contrast it with forEach, forEach (barely!) pays 
>> for itself by allowing things like:
>> 
>>  collection.forEach(curriedMethod)
>> 
>> That benefit doesn’t translate to “.times".
>> 
>> -Chris
> 
> Thanks for weighing in!
> 
> The benefit of `5.times` vs `repeat 5` is that the former is (and can easily 
> be) defined in Swift, not as a language-level feature. OTOH `repeat 5` is a 
> bit more useful because it allows returning/breaking/etc.
> 
> But I also understand the argument that this feature isn’t worth it at all. 
> (There’s already a lot of libraries extending stdlib with things of this 
> sort!)

It’s important to differentiate “not interesting” vs “not appropriate to 
include in the swift standard library”.  I love that you can express things 
like that directly in the language, and if someone felt compelled to do that in 
their own code (or in a SPM package someday) that would be fine with me.  It 
just shouldn’t (again, IMO) come with swift out of the box.

-Chris
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Proposal: Add .times method to Integer type

[Cihat Gündüz via swift-evolution]

I agree with Radek. I find `for i in 5 { doSomething() }` or `for 5 { 
doSomething() }` to be very confusing since it is neither close to human 
language nor to any common programming language I know of.

I like the idea of giving students a step by step introduction into things, but 
this is IMO not the right way/place to do that.

– Cihat


> Am 18.12.2015 um 22:26 schrieb Radosław Pietruszewski via swift-evolution 
> :
> 
>> An obvious question is, should it be equivalent to 1...n, or 0.. 
> I think that’s exactly why this isn’t a good idea. The semantics of `for i in 
> 5` are not immediately clear at all.
> 
> If this was to be a language feature, `repeat 5`, suggested by Chris, seems 
> like the least-ambiguous choice.
> 
> — Radek
> 
>> On 18 Dec 2015, at 22:09, Jacob Bandes-Storch via swift-evolution 
>> > wrote:
>> 
>> This can be done pretty easily, although I think the approach has the 
>> potential to cause confusion elsewhere in code. An obvious question is, 
>> should it be equivalent to 1...n, or 0..> 
>> extension Int: SequenceType {
>> public func generate() -> RangeGenerator {
>> return (0..> }
>> }
>> 
>> for i in 5 {
>> print("hello \(i)")
>> }
>> 
>> Jacob Bandes-Storch
>> 
>> On Fri, Dec 18, 2015 at 1:03 PM, Brent Royal-Gordon via swift-evolution 
>> > wrote:
>> > I’d like to propose an addition of a useful method, especially for 
>> > beginners that also makes Swift much more readable in some situations: The 
>> > addition of a .times method to Integer type(s).
>> 
>> I’ve said it before, but I don’t think `times` is a good solution for 
>> learners. It teaches them a form of looping they will never use in practice 
>> and does not allow them to practice with ancillary loop skills like `break` 
>> and `continue`.
>> 
>> I think our best bet is to extend the `for` loop to allow a single number, 
>> meaning either `1…n` or `0..> allow the `variableName in` part to be omitted, meaning `_ in`. This gives 
>> us the pedagogical simplicity of a “do this N times” loop, but couches it in 
>> a form where, when the student moves on, more commonly used loop forms are a 
>> straightforward extension of that simple case.
>> 
>> for 5 { print(“Hello!”) }
>> for i in 5 { print(“Hello \(i)!”) }
>> for i in 10..<20 { print(“Hello \(i)!”) }
>> for i in 10...20 { print(“Hello \(i)!”) }
>> 
>> --
>> Brent Royal-Gordon
>> Architechies
>> 
>> ___
>> 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

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution