Re: [swift-evolution] Removing enumerated?

[Shawn Erickson via swift-evolution]

I use enumerated in many location in my code and have never expected it to
be indexes but a counting of how many times I have looped. It says clearly
what is does on the tin: "Returns a sequence of pairs (n, x), where n
represents a consecutive integer starting at zero, and x represents an
element of the sequence.". I get some new folks have confusion but reading
the docs is always part of learning IMHO.

I would hate to see it removed without strong replacement that is
reasonably readable. I think leveraging zip and the potential range style
is on the edge of being readable but is learnable.

-Shawn
On Fri, Feb 3, 2017 at 4:11 PM Erica Sadun via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > On Feb 3, 2017, at 4:20 PM, Dave Abrahams  wrote:
> >
> >
> > on Fri Feb 03 2017, Erica Sadun  wrote:
> >
> >>> On Feb 3, 2017, at 2:58 PM, Ben Cohen  wrote:
> >>>
> >>>
>  On Feb 3, 2017, at 11:12 AM, Erica Sadun via swift-evolution <
> swift-evolution@swift.org
> >> > wrote:
> 
> >>
>  I believe what people *want* is `indexed` over `enumerated`, and
> consistently for both array and array slices.
> 
> >>>
> >>> I don’t know if that’s true.
> >>>
> >>> Here’s an example (the only use of enumerated) from Alamofire:
> >>>
> >>> let acceptLanguage =
> Locale.preferredLanguages.prefix(6).enumerated().map { index, languageCode
> in
> >>>let quality = 1.0 - (Double(index) * 0.1)
> >>>return "\(languageCode);q=\(quality)"
> >>> }.joined(separator: ", ")
> >>>
> >>> Here the intent is a counter, not indices. They just happen to be the
> same. But if they’d used indexed() it would certainly hurt readability,
> albeit midly.
> >>>
> >>> Suppose there wasn’t an enumerate or an indexed, and zipped was the
> standard way of doing it. That might lead to another solution:
> >>>
> >>> let qualities = stride(from: 1.0, to: 0.4, by: -0.1)
> >>> let acceptLanguage = Locale.preferredLanguages.zipped(with:
> qualities).map {
> >>>languageCode, quality in "\(languageCode);q=\(quality)"
> >>> }.joined(separator: ", ")
> >>>
> >>> The use of stride here feels more what was intended, rather than
> >>> backing into the quality via an “index” value. And avoids any risk
> >>> with indexed of this getting applied incorrectly to slices.
> >>>
> >>
> >> I think enumerated as it stands is an attractive nuisance / moral
> >> hazard. Most of the language learners I interact with miss the point
> >> and the nuance of how it works.
> >>
> >> let list = [0, 1, 2, 3, 4]
> >> let slice = list[2...3]
> >> for (idx, value) in slice.enumerated() {
> >>print(idx, value)
> >> }
> >>
> >> I think people would not expect 0, 2 / 1, 3. I also don’t think they’d
> >> expect the actual outcome from a dictionary, whether index or
> >> enumeration because there’s no inherent semantic “enumeration” of
> >> dictionary values:
> >>
> >> let dict = [0:"a", 1:"b", 2:"c"]
> >> for (idx, value) in dict.enumerated() {
> >>print(idx, value)
> >> }
> >>
> >> 0 (2, "c")
> >> 1 (0, "a")
> >> 2 (1, "b")
> >>
> >> I’d like to see enumerated gone and I have a mild preference for
> >> introducing indexed, either under its own name or as a new behavior
> >> for enumerated (although T where T.Iterator.Element is Int)
> >>
> >> 120 gists with “enumerated”, of which a casual scan shows that almost
> >> none of them are actually using it meaningfully. (Take a look.) I
> >> think I did this API right:
> >> https://api.github.com/search/repositories?q=enumerate+language:swift
> >> 
> >> and if so, not much in repos.
> >
> > Ben's not arguing that enumerated should stay.  He's just saying that
> > there's no good reason to provide indexed(), and I agree with that.
> >
> > --
> > -Dave
>
> And I think I just argued my way to agreeing with him.
>
> -- E
>
>
> ___
> 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] Annotation of Warnings/Errors

[Derrick Ho via swift-evolution]

I feel like warnings showing up as you type are an IDE's responsibility.

Annotations to delay warnings seem like noise.  Once you get used to
programming you don't need the annotations.

If warnings are bothersome, then turn it off in the Xcode settings!




On Thu, Feb 2, 2017 at 1:34 PM Pierre Monod-Broca via swift-evolution <
swift-evolution@swift.org> wrote:

+1 to the proposal
+1 to teach how to remove live issues to beginners, so they have a chance
to train at detecting errors without the compiler



Pierre

Le 2 févr. 2017 à 17:48, Nicolas Fezans via swift-evolution <
swift-evolution@swift.org> a écrit :

+1

On Tue, Jan 31, 2017 at 11:55 AM, Tino Heth via swift-evolution <
swift-evolution@swift.org> wrote:

One of the biggest issues that I saw while teaching Swift to newbies (most
had not programmed before) is confusion based on the early warnings/errors
that swift/xcode gives you as they type.  What would happen is that they
would type a variable, and it would say… “You haven’t used this variable”
and so they would just click the fixit because they trust the compiler more
than they trust themselves.  This would lead to a point where they were
very confused because some of the code was code they had thought through,
and some of it was changed by random fixits in ways they didn’t understand…
and so it would lead to more errors/fixits until they had errors which
couldn’t be fixed.


Imho this is the best example to illustrate that inflationary use of
warnings does more harm than good, and I hope it will be fixed.

Having a bunch of conditions for warnings looks like overkill to me, and
there are alternatives:
- Only show when building
- Only show in release builds
- Linter

That said, I'm going out on a limb and claim I already know how to write
code and don't need basic schooling, and showing warnings before I hit
compile is merely a distraction.

But there are also Playgrounds which seem to be an important aspect of
Swift, especially for newbies who could really benefit from some hints.
There are no linters, no release builds, and even no regular builds for
Playgrounds, so your model is the only one that works for them.

Bottom line:
+1

___
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

Re: [swift-evolution] Removing enumerated?

[Erica Sadun via swift-evolution]

> On Feb 3, 2017, at 4:20 PM, Dave Abrahams  wrote:
> 
> 
> on Fri Feb 03 2017, Erica Sadun  wrote:
> 
>>> On Feb 3, 2017, at 2:58 PM, Ben Cohen  wrote:
>>> 
>>> 
 On Feb 3, 2017, at 11:12 AM, Erica Sadun via swift-evolution 
 > > wrote:
 
>> 
 I believe what people *want* is `indexed` over `enumerated`, and 
 consistently for both array and array slices.
 
>>> 
>>> I don’t know if that’s true.
>>> 
>>> Here’s an example (the only use of enumerated) from Alamofire:
>>> 
>>> let acceptLanguage = Locale.preferredLanguages.prefix(6).enumerated().map { 
>>> index, languageCode in
>>>let quality = 1.0 - (Double(index) * 0.1)
>>>return "\(languageCode);q=\(quality)"
>>> }.joined(separator: ", ")
>>> 
>>> Here the intent is a counter, not indices. They just happen to be the same. 
>>> But if they’d used indexed() it would certainly hurt readability, albeit 
>>> midly.
>>> 
>>> Suppose there wasn’t an enumerate or an indexed, and zipped was the 
>>> standard way of doing it. That might lead to another solution:
>>> 
>>> let qualities = stride(from: 1.0, to: 0.4, by: -0.1)
>>> let acceptLanguage = Locale.preferredLanguages.zipped(with: qualities).map {
>>>languageCode, quality in "\(languageCode);q=\(quality)"
>>> }.joined(separator: ", ")
>>> 
>>> The use of stride here feels more what was intended, rather than
>>> backing into the quality via an “index” value. And avoids any risk
>>> with indexed of this getting applied incorrectly to slices.
>>> 
>> 
>> I think enumerated as it stands is an attractive nuisance / moral
>> hazard. Most of the language learners I interact with miss the point
>> and the nuance of how it works.
>> 
>> let list = [0, 1, 2, 3, 4]
>> let slice = list[2...3]
>> for (idx, value) in slice.enumerated() {
>>print(idx, value)
>> }
>> 
>> I think people would not expect 0, 2 / 1, 3. I also don’t think they’d
>> expect the actual outcome from a dictionary, whether index or
>> enumeration because there’s no inherent semantic “enumeration” of
>> dictionary values:
>> 
>> let dict = [0:"a", 1:"b", 2:"c"]
>> for (idx, value) in dict.enumerated() {
>>print(idx, value)
>> }
>> 
>> 0 (2, "c")
>> 1 (0, "a")
>> 2 (1, "b")
>> 
>> I’d like to see enumerated gone and I have a mild preference for
>> introducing indexed, either under its own name or as a new behavior
>> for enumerated (although T where T.Iterator.Element is Int)
>> 
>> 120 gists with “enumerated”, of which a casual scan shows that almost
>> none of them are actually using it meaningfully. (Take a look.) I
>> think I did this API right:
>> https://api.github.com/search/repositories?q=enumerate+language:swift
>> 
>> and if so, not much in repos.
> 
> Ben's not arguing that enumerated should stay.  He's just saying that
> there's no good reason to provide indexed(), and I agree with that.
> 
> -- 
> -Dave

And I think I just argued my way to agreeing with him.

-- E


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

Re: [swift-evolution] Removing enumerated?

[Ben Cohen via swift-evolution]

> On Feb 3, 2017, at 3:27 PM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> I don't always make zip a method, but when I do, its argument label is
> “to:”

Hmm, that doesn’t sound very natural to me.

Then again the problem with “zip(with:)" is it’s already kind of a term of art 
for a version that takes a function to combine the two values.

There’s also the question of how to spell a non-truncating versions (returning 
optionals or taking a pad value).

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

Re: [swift-evolution] Removing enumerated?

[Haravikk via swift-evolution]

I'm in favour of getting rid of enumerated; I think like many people I used it 
expecting to get actual indices, and it's very easy to think this when working 
with arrays (as the values will in fact be perfectly valid). In reality the 
right way to do it is with one of the following:

for eachIndex in myArray.indices { print("\(eachIndex): " + myArray[eachIndex]) 
}
for eachIndex in myArray.startIndex ..< myArray.endIndex { print("\(eachIndex): 
" + myArray[eachIndex]) }
var offset = 0; for eachEntry in myArray { print("\(offset): \(eachEntry)"); 
offset += 1 }

However, I think I'd still support the inclusion of an enumerating and an 
indexing type that sequences/collections can be wrapped in to perform 
enumeration/indexing if you still want it.

> On 31 Jan 2017, at 14:24, Chris Eidhof via swift-evolution 
>  wrote:
> 
> Hey everyone,
> 
> I've organized a number of Swift workshops over the last two years. There are 
> a couple of things that keep coming up, and a couple of mistakes that I see 
> people making over and over again. One of them is that in almost every 
> workshop, there's someone who thinks that `enumerated()` returns a list of 
> (index, element) pairs. This is only true for arrays. It breaks when using 
> array slices, or any other kind of collection. In our workshops, I sometimes 
> see people doing something like `x.reversed().enumerated()`, where `x` is an 
> array, and somehow it produces behavior they don't understand.
> 
> A few ways I think this could be improved:
> 
> - Move enumerated to Array
> - Change enumerated to return `(Index, Iterator.Element)` (this would mean we 
> at least need to move it to collection)
> - Remove enumerated
> - Keep things as is
> 
> In any case, just wanted to share my experience (gained from teaching 
> people). 
> 
> -- 
> Chris Eidhof
> ___
> 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] Removing enumerated?

[Dave Abrahams via swift-evolution]

on Fri Feb 03 2017, Ben Cohen  wrote:

>> On Feb 2, 2017, at 8:46 PM, Chris Lattner 
> wrote:
>> 
>> It seems that you are leaning towards removing enumerated(). 
>
> I’m actually kind of conflicted.
>
> Replacing enumerated() with indexed() feels replacing one problem for
> another. Sometimes people want to number things, and might assume
> indexed() will be zero-based for slices.
>
> Adding indexed() while keeping enumerated() seems too much clutter on
> the API though. Once we have 0… both can be expressed simply with zip,
> and in my view is zip(a, 0…), zip(a, a.indices), zip(1…, a) just as
> clear, maybe clearer in some cases as they will encourage code to show
> intent more (i.e. are you counting or indexing? even when they are the
> same, it’s better to say which). Encouraging learning about zip will
> also help introduce people to better ways of expressing other
> similar-but-different loops.
>
> The trouble with zip is it isn’t discoverable – another entry that
> probably belongs on that list of criteria. Unlike enumerated, users
> aren’t going to stumble over it.
>
> Maybe moving zip to be a method on Sequence rather than a free
> function would help with this? e.g. something like a.zipped(with: 0…),
> a.zipped(with: a.indices). The documentation for it could even
> explicitly mention the counting and index use cases. The main downside
> is it pushes the order of the lhs/rhs to be self first.

I don't always make zip a method, but when I do, its argument label is
“to:”

-- 
-Dave

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

Re: [swift-evolution] Removing enumerated?

[Dave Abrahams via swift-evolution]

on Fri Feb 03 2017, Erica Sadun  wrote:

>> On Feb 3, 2017, at 2:58 PM, Ben Cohen  wrote:
>> 
>> 
>>> On Feb 3, 2017, at 11:12 AM, Erica Sadun via swift-evolution 
>>>  > wrote:
>>> 
>
>>> I believe what people *want* is `indexed` over `enumerated`, and 
>>> consistently for both array and array slices.
>>> 
>> 
>> I don’t know if that’s true.
>> 
>> Here’s an example (the only use of enumerated) from Alamofire:
>> 
>> let acceptLanguage = Locale.preferredLanguages.prefix(6).enumerated().map { 
>> index, languageCode in
>> let quality = 1.0 - (Double(index) * 0.1)
>> return "\(languageCode);q=\(quality)"
>> }.joined(separator: ", ")
>> 
>> Here the intent is a counter, not indices. They just happen to be the same. 
>> But if they’d used indexed() it would certainly hurt readability, albeit 
>> midly.
>> 
>> Suppose there wasn’t an enumerate or an indexed, and zipped was the standard 
>> way of doing it. That might lead to another solution:
>> 
>> let qualities = stride(from: 1.0, to: 0.4, by: -0.1)
>> let acceptLanguage = Locale.preferredLanguages.zipped(with: qualities).map {
>> languageCode, quality in "\(languageCode);q=\(quality)"
>> }.joined(separator: ", ")
>> 
>> The use of stride here feels more what was intended, rather than
>> backing into the quality via an “index” value. And avoids any risk
>> with indexed of this getting applied incorrectly to slices.
>> 
>
> I think enumerated as it stands is an attractive nuisance / moral
> hazard. Most of the language learners I interact with miss the point
> and the nuance of how it works.
>
> let list = [0, 1, 2, 3, 4]
> let slice = list[2...3]
> for (idx, value) in slice.enumerated() {
> print(idx, value)
> }
>
> I think people would not expect 0, 2 / 1, 3. I also don’t think they’d
> expect the actual outcome from a dictionary, whether index or
> enumeration because there’s no inherent semantic “enumeration” of
> dictionary values:
>
> let dict = [0:"a", 1:"b", 2:"c"]
> for (idx, value) in dict.enumerated() {
> print(idx, value)
> }
>
> 0 (2, "c")
> 1 (0, "a")
> 2 (1, "b")
>
> I’d like to see enumerated gone and I have a mild preference for
> introducing indexed, either under its own name or as a new behavior
> for enumerated (although T where T.Iterator.Element is Int)
>
> 120 gists with “enumerated”, of which a casual scan shows that almost
> none of them are actually using it meaningfully. (Take a look.) I
> think I did this API right:
> https://api.github.com/search/repositories?q=enumerate+language:swift
> 
> and if so, not much in repos.

Ben's not arguing that enumerated should stay.  He's just saying that
there's no good reason to provide indexed(), and I agree with that.

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

Re: [swift-evolution] Removing enumerated?

[Erica Sadun via swift-evolution]

> On Feb 3, 2017, at 2:58 PM, Ben Cohen  wrote:
> 
> 
>> On Feb 3, 2017, at 11:12 AM, Erica Sadun via swift-evolution 
>> > wrote:
>> 
>> I believe what people *want* is `indexed` over `enumerated`, and 
>> consistently for both array and array slices.
>> 
> 
> I don’t know if that’s true.
> 
> Here’s an example (the only use of enumerated) from Alamofire:
> 
> let acceptLanguage = Locale.preferredLanguages.prefix(6).enumerated().map { 
> index, languageCode in
> let quality = 1.0 - (Double(index) * 0.1)
> return "\(languageCode);q=\(quality)"
> }.joined(separator: ", ")
> 
> Here the intent is a counter, not indices. They just happen to be the same. 
> But if they’d used indexed() it would certainly hurt readability, albeit 
> midly.
> 
> Suppose there wasn’t an enumerate or an indexed, and zipped was the standard 
> way of doing it. That might lead to another solution:
> 
> let qualities = stride(from: 1.0, to: 0.4, by: -0.1)
> let acceptLanguage = Locale.preferredLanguages.zipped(with: qualities).map {
> languageCode, quality in "\(languageCode);q=\(quality)"
> }.joined(separator: ", ")
> 
> The use of stride here feels more what was intended, rather than backing into 
> the quality via an “index” value. And avoids any risk with indexed of this 
> getting applied incorrectly to slices.
> 

I think enumerated as it stands is an attractive nuisance / moral hazard. Most 
of the language learners I interact with miss the point and the nuance of how 
it works.

let list = [0, 1, 2, 3, 4]
let slice = list[2...3]
for (idx, value) in slice.enumerated() {
print(idx, value)
}

I think people would not expect 0, 2 / 1, 3. I also don’t think they’d expect 
the actual outcome from a dictionary, whether index or enumeration because 
there’s no inherent semantic “enumeration” of dictionary values:

 
let dict = [0:"a", 1:"b", 2:"c"]
for (idx, value) in dict.enumerated() {
print(idx, value)
}

0 (2, "c")
1 (0, "a")
2 (1, "b")

I’d like to see enumerated gone and I have a mild preference for introducing 
indexed, either under its own name or as a new behavior for enumerated 
(although T where T.Iterator.Element is Int)

120 gists with “enumerated”, of which a casual scan shows that almost none of 
them are actually using it meaningfully. (Take a look.) I think I did this API 
right: https://api.github.com/search/repositories?q=enumerate+language:swift 
 and if 
so, not much in repos.


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

Re: [swift-evolution] Removing enumerated?

[Ben Cohen via swift-evolution]

> On Feb 3, 2017, at 11:12 AM, Erica Sadun via swift-evolution 
>  wrote:
> 
> I believe what people *want* is `indexed` over `enumerated`, and consistently 
> for both array and array slices.
> 

I don’t know if that’s true.

Here’s an example (the only use of enumerated) from Alamofire:

let acceptLanguage = Locale.preferredLanguages.prefix(6).enumerated().map { 
index, languageCode in
let quality = 1.0 - (Double(index) * 0.1)
return "\(languageCode);q=\(quality)"
}.joined(separator: ", ")

Here the intent is a counter, not indices. They just happen to be the same. But 
if they’d used indexed() it would certainly hurt readability, albeit midly.

Suppose there wasn’t an enumerate or an indexed, and zipped was the standard 
way of doing it. That might lead to another solution:

let qualities = stride(from: 1.0, to: 0.4, by: -0.1)
let acceptLanguage = Locale.preferredLanguages.zipped(with: qualities).map {
languageCode, quality in "\(languageCode);q=\(quality)"
}.joined(separator: ", ")

The use of stride here feels more what was intended, rather than backing into 
the quality via an “index” value. And avoids any risk with indexed of this 
getting applied incorrectly to slices.



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

Re: [swift-evolution] Removing enumerated?

[Matthew Johnson via swift-evolution]

> On Feb 3, 2017, at 3:41 PM, Ben Cohen via swift-evolution 
>  wrote:
> 
> 
>> On Feb 2, 2017, at 8:46 PM, Chris Lattner > > wrote:
>> 
>> It seems that you are leaning towards removing enumerated(). 
> 
> I’m actually kind of conflicted.
> 
> Replacing enumerated() with indexed() feels replacing one problem for 
> another. Sometimes people want to number things, and might assume indexed() 
> will be zero-based for slices.
> 
> Adding indexed() while keeping enumerated() seems too much clutter on the API 
> though. Once we have 0… both can be expressed simply with zip, and in my view 
> is zip(a, 0…), zip(a, a.indices), zip(1…, a) just as clear, maybe clearer in 
> some cases as they will encourage code to show intent more (i.e. are you 
> counting or indexing? even when they are the same, it’s better to say which). 
> Encouraging learning about zip will also help introduce people to better ways 
> of expressing other similar-but-different loops.
> 
> The trouble with zip is it isn’t discoverable – another entry that probably 
> belongs on that list of criteria. Unlike enumerated, users aren’t going to 
> stumble over it.
> 
> Maybe moving zip to be a method on Sequence rather than a free function would 
> help with this? e.g. something like a.zipped(with: 0…), a.zipped(with: 
> a.indices). The documentation for it could even explicitly mention the 
> counting and index use cases. The main downside is it pushes the order of the 
> lhs/rhs to be self first.

I think the downside is significant.  I think the visual relationship of 
`zip(a, 0…)` with the tuples it produces is pretty important.  It also scales 
well if (when?) it becomes variadic.

Discoverability is a problem, but no more so than with any other top level 
operator somebody might not be familiar with (Swift has a few of those 
depending on somebody’s background)

I think the discoverability problem is best addressed by identifying and 
raising awareness of common use cases for zip rather than just moving it so it 
appears in autocomplete.  When people learn how it can make their code better 
they will use it.

> 
> 
> 
> ___
> 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] Removing enumerated?

[Ben Cohen via swift-evolution]

> On Feb 2, 2017, at 8:46 PM, Chris Lattner  wrote:
> 
> It seems that you are leaning towards removing enumerated(). 

I’m actually kind of conflicted.

Replacing enumerated() with indexed() feels replacing one problem for another. 
Sometimes people want to number things, and might assume indexed() will be 
zero-based for slices.

Adding indexed() while keeping enumerated() seems too much clutter on the API 
though. Once we have 0… both can be expressed simply with zip, and in my view 
is zip(a, 0…), zip(a, a.indices), zip(1…, a) just as clear, maybe clearer in 
some cases as they will encourage code to show intent more (i.e. are you 
counting or indexing? even when they are the same, it’s better to say which). 
Encouraging learning about zip will also help introduce people to better ways 
of expressing other similar-but-different loops.

The trouble with zip is it isn’t discoverable – another entry that probably 
belongs on that list of criteria. Unlike enumerated, users aren’t going to 
stumble over it.

Maybe moving zip to be a method on Sequence rather than a free function would 
help with this? e.g. something like a.zipped(with: 0…), a.zipped(with: 
a.indices). The documentation for it could even explicitly mention the counting 
and index use cases. The main downside is it pushes the order of the lhs/rhs to 
be self first.



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

[swift-evolution] Package manager support for versioning (both language and tools)

[Rick Ballard via swift-evolution]

As part of Swift source compatibility, the Swift compiler added a new flag for 
controlling what Swift language version should be used to compile with. 
Currently there is no good way to specify this for Swift packages. We've got a 
proposal ready that provides a mechanism for controlling this. I'd appreciate 
any feedback the community would like addressed before this goes through 
evolution review.

The Swift language version support proposal can be viewed and commented on at 
https://github.com/rballard/swift-evolution/pull/2/files

Additionally, we are proposing to introduce a "Swift minimum tools version" 
mechanism for Swift packages. This mechanism will allow us to evolve the 
package manager – adding new API, and doing a one-time revision of our existing 
API for Swift 4 – without breaking the package ecosystem. It will also manage 
the Swift 3–>4 language transition for Package.swift files themselves. This is 
a pretty lengthy proposal, but I'd appreciate any important feedback before 
this goes to evolution review. There is also one decision left to make before 
this proposal is final; I lay out several possibilities for how we could store 
the "Swift tools version". I'd appreciate feedback on which of the 
possibilities we should pick before I bring this to review.

The Swift tools version support proposal can be viewed and commented on at 
https://github.com/rballard/swift-evolution/pull/1/files

Absent any serious feedback which requires us to make major revisions, I'm 
expecting to bring both of these to Swift evolution review early next week.

Thank you,

- Rick

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

Re: [swift-evolution] Removing enumerated?

[Erica Sadun via swift-evolution]

> On Feb 3, 2017, at 10:57 AM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
> on Thu Feb 02 2017, Chris Lattner  > wrote:
> 
>> On Jan 31, 2017, at 11:16 AM, Ben Cohen via swift-evolution 
>>  wrote:
>>> 
>>> As we expand (and maybe contract :) the standard library, this kind
>>> of question comes up a lot, so it is worth setting out some criteria
>>> for judging these “helper” methods. Here’s my take on such a list
>>> (warning: objectivity and subjectivity blended together in the
>>> below).
>> 
>> This is great perspective Ben, thank you for taking time to write this up!
>> 
>> It seems that you are leaning towards removing enumerated().  What do
>> you think about the proposal of removing enumerated but adding
>> indexed() to replace it?  It would provide the same behavior for
>> common array cases, while providing more useful/defensible
>> functionality for other collections.
> 
> indexed() is trivially composed from other library primitives:
> 
>  zip(c.indices, c)
> 
> enumerated() only exists in the standard library, and was explicitly
> designed as it was, because what it does is not currently easy to
> write.  As soon as we enable "0...", that changes.
> 
> I'm not against having trivial helper functions in principle, but I
> don't think the Standard Library or the language is yet at the stage of
> maturity where we can see clearly which ones are important enough, and
> pay for the API surface area they add.  For that reason I feel strongly
> that for the time being we should remain very conservative about adding
> such things, and only introduce them where there's real compelling
> evidence that they are a win.  There is no such evidence for indexed()
> as far as I can tell.

I believe what people *want* is `indexed` over `enumerated`, and consistently 
for both array and array slices.

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

[swift-evolution] [Accepted] SE-0150: Package Manager Support for branches

[Daniel Dunbar via swift-evolution]

Proposal Link: 
https://github.com/apple/swift-evolution/blob/master/proposals/0150-package-manager-branch-support.md

The review of SE-0150 "Package Manager Support for branches" ran from January 
24…31. Feedback was positive, and the proposal is accepted for Swift 4. Thanks 
to everyone who participated!

- Daniel
Review Manager

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

[swift-evolution] [Accepted] SE-0149: Package Manager Support for Top of Tree development

[Daniel Dunbar via swift-evolution]

Proposal Link: 
https://github.com/apple/swift-evolution/blob/master/proposals/0149-package-manager-top-of-tree.md

The review of SE-0149 "Package Manager Support for Top of Tree development" ran 
from January 24…31. Feedback was positive, and the proposal is accepted for 
Swift 4. Thanks to everyone who participated!

 - Daniel
Review Manager

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

Re: [swift-evolution] Initializers

[Joe Groff via swift-evolution]

> On Jan 31, 2017, at 3:52 AM, Victor Petrescu via swift-evolution 
>  wrote:
> 
> 4. Joe Groff says there is already a backdoor of sorts ("There already is a 
> backdoor of sorts. This is one of the intended use cases for 
> implicitly-unwrapped optionals. If you don't want to be hassled by DI, 
> declare a property as T! type, and it will be implicitly initialized to nil, 
> and trap if you try to use it as an unwrapped T without initializing it 
> first."): I'm assuming by T you mean generics. If that is true that may 
> already solve the problem but... generics are a new concept for me (first 
> time I really encountered and used them is now, in swift) but to my 
> understanding their role is to deal with cases you don't know the type. Can 
> you please show how to use this to work around the posted issue?
> 
> Sidenote: There may be another workaround using optionals (Joe Groff answer 
> made it pop in my mind) but... I know the type and value for the variable, it 
> is not optional or nil. Unwrapping each time someone needs it does not look 
> like the best solution to me.

You don't need to understand generics to use implicitly-unwrapped optionals. By 
`T!` I was referring to the syntax used to represent them; you would write Int! 
or String! or whatever in your code. For your example, this would let you avoid 
having to invoke super.init() before resetting `x`:

class A {
 var x:Int! // Int! is nil by default
}

class B : A {
override init() {
 x = 2 // So we can set it here w/o super.init first
}
}

print(B().x + 1) // and we don't need to explicitly unwrap it to use it, unlike 
`Int?`

You're giving up the static guarantee that `x` has a value, so you'll get a 
runtime error if you try to use it before it's initialized, but that's the same 
situation you have in Java, where dereferencing an uninitialized object 
reference gives an NPE. Whether you want the hard guarantee that `x` is never 
optional from the compiler, or the convenience of leaving that up to runtime 
checks, is a call you have to make; Swift defaults to the strong guarantee, but 
implicitly-unwrapped optional types like Int! are intended to give you an out 
if the static model is too strict or inefficient.

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

Re: [swift-evolution] [draft] Compound Names For Enum Cases

[Dennis Weissmann via swift-evolution]

I'm also +1 on this, wanted this for a long time :)

- Dennis

> On Feb 2, 2017, at 2:42 PM, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> Great, thanks. Love it :) 
> 
> +1 
> 
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 2. Februar 2017 um 14:39:43, Daniel Duan (dan...@duan.org 
> ) schrieb:
> 
>> This has been answered in various forms in the thread. Short answer: yes.
>> 
>> On Feb 2, 2017, at 2:05 AM, Adrian Zubarev > > wrote:
>> 
>>> Is that correct that this proposal will add some sort of overloading enum 
>>> cases by different labels?
>>> 
>>> enum Foo {
>>> case foo(a: Int)
>>> case foo(a: Int, b: Int)
>>> }   
>>> Is Foo a valid enum after this proposal?
>>> 
>>> 
>>> 
>>> -- 
>>> Adrian Zubarev
>>> Sent with Airmail
>>> 
>>> Am 19. Januar 2017 um 19:37:50, Daniel Duan via swift-evolution 
>>> (swift-evolution@swift.org ) schrieb:
>>> 
 Hi all,
 
 Here’s a short proposal for fixing an inconsistency in Swift’s enum. 
 Please share you feedback :)
 
 (Updating/rendered version: 
 https://github.com/dduan/swift-evolution/blob/compound-names-for-enum-cases/proposals/-Compound-Names-For-Enum-Cases.md
  
 )
 
 
 ## Introduction
 
 Argument labels are part of its function's declaration name. An enum case
 declares a function that can be used to construct enum values. For cases 
 with
 associated values, their labels should be part of the constructor name, 
 similar
 to "normal" function and methods. In Swift 3, however, this is not true. 
 This
 proposal aim to change that.
 
 ## Motivation
 
 After SE-0111, Swift function's fully qualified name consists of its base 
 name
 and all argument labels. As a example, one can invoke a function with its
 fully name:
 
 ```swift
 func f(x: Int, y: Int) {}
 
 f(x: y:)(0, 0) // Okay, this is equivalent to f(x: 0, y: 0)
 ```
 
 This, however, is not true when enum cases with associated value were
 constructed:
 
 ```swift
 enum Foo {
 case bar(x: Int, y: Int)
 }
 
 Foo.bar(x: y:)(0, 0) // Does not compile as of Swift 3
 ```
 
 Here, the declared name for the case is `foo`; it has a tuple with two 
 labeled
 fields as its associated value. `x` and `y` aren't part of the case name. 
 This
 inconsistency may surprise some users.
 
 Using tuple to implement associated value also limits us from certain 
 layout
 optimizations as each payload need to be a tuple first, as opposed to 
 simply be
 unique to the enum.
 
 ## Proposed solution
 
 Include labels in enum case's declaration name. In the last example, 
 `bar`'s
 full name would become `bar(x:y:)`, `x` and `y` will no longer be labels 
 in a
 tuple. The compiler may also stop using tuple to represent associated 
 values.
 
 ## Detailed design
 
 When labels are present in enum cases, they are now part of case's 
 declared name
 instead of being labels for fields in a tuple. In details, when 
 constructing an
 enum value with the case name, label names must either be supplied in the
 argument list it self, or as part of the full name.
 
 ```swift
 Foo.bar(x: 0, y: 0) // Okay, the Swift 3 way.
 Foo.bar(x: y:)(0, 0) // Equivalent to the previous line.
 Foo.bar(x: y:)(x: 0, y: 0) // This would be an error, however.
 ```
 
 Note that since the labels aren't part of a tuple, they no longer 
 participate in
 type checking, similar to functions:
 
 ```swift
 let f = Foo.bar // f has type (Int, Int) -> Foo
 f(0, 0) // Okay!
 f(x: 0, y: 0) // Won't compile.
 ```
 
 ## Source compatibility
 
 Since type-checking rules on labeled tuple is stricter than that on 
 function
 argument labels, existing enum value construction by case name remain 
 valid.
 This change is source compatible with Swift 3.
 
 ## Effect on ABI stability and resilience
 
 This change introduces compound names for enum cases, which affects their
 declaration's name mangling.
 
 The compiler may also choose to change enum payload's representation from 
 tuple.
 This may open up more space for improving enum's memory layout.
 
 ## Alternatives considered
 
 Keep current behaviors, which means we live with the inconsistency.
 
 ___
 swift-evolution mailing list
 swift-evolution@swift.org 
 

Re: [swift-evolution] Removing enumerated?

[Dave Abrahams via swift-evolution]

on Thu Feb 02 2017, Chris Lattner  wrote:

> On Jan 31, 2017, at 11:16 AM, Ben Cohen via swift-evolution 
>  wrote:
>> 
>> As we expand (and maybe contract :) the standard library, this kind
>> of question comes up a lot, so it is worth setting out some criteria
>> for judging these “helper” methods. Here’s my take on such a list
>> (warning: objectivity and subjectivity blended together in the
>> below).
>
> This is great perspective Ben, thank you for taking time to write this up!
>
> It seems that you are leaning towards removing enumerated().  What do
> you think about the proposal of removing enumerated but adding
> indexed() to replace it?  It would provide the same behavior for
> common array cases, while providing more useful/defensible
> functionality for other collections.

indexed() is trivially composed from other library primitives:

  zip(c.indices, c)

enumerated() only exists in the standard library, and was explicitly
designed as it was, because what it does is not currently easy to
write.  As soon as we enable "0...", that changes.

I'm not against having trivial helper functions in principle, but I
don't think the Standard Library or the language is yet at the stage of
maturity where we can see clearly which ones are important enough, and
pay for the API surface area they add.  For that reason I feel strongly
that for the time being we should remain very conservative about adding
such things, and only introduce them where there's real compelling
evidence that they are a win.  There is no such evidence for indexed()
as far as I can tell.

-- 
-Dave

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

Re: [swift-evolution] for-else syntax

[Dave Abrahams via swift-evolution]

on Fri Feb 03 2017, Dimitri Racordon  wrote:

> Talking of Python, Swift is not Python and the argument not to
> implement a feature because its semantics conflict with the semantics
> of a similar looking feature in another language is bogus. 

I don't have a anything to say about for-else, but just a comment on the
meta-point of how we evaluate designs: precedent set by other languages
affects learnability, and is one of the criteria we've always considered
when designing Swift.

HTH,

-- 
-Dave

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

Re: [swift-evolution] Strings in Swift 4

[Dave Abrahams via swift-evolution]

on Thu Feb 02 2017, Xiaodi Wu  wrote:

> On Thu, Feb 2, 2017 at 9:45 AM, Dave Abrahams via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> If indeed the desired semantics for ranges is that they should continue to
> lack precise semantics, then an agreement that we are going into this
> deliberately and clear documentation to that effect is the next best thing,
> I suppose.

Practically speaking, using the type system to separate ranges that are
collections from the ones that merely bound some values would not be
helpful to anyone, IMO.  If that's what you mean by saying ranges have
imprecise semantics, then that's what I, at least, desire.

A more powerful way to look at it, IMO, is that ranges unambiguously
represent one or two bounds on comparable values, and there are
operations that combine those bounds with other entities (for loops,
collections whose indices match the ranges) in useful ways.

-- 
-Dave

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

Re: [swift-evolution] for-else syntax

[Erica Sadun via swift-evolution]

I'm not really seeing the advantage of `for item in collection else` being 
discussed or a compelling use case that motivates a language change.

You can check the empty case first for empty collections:

if collection.isEmpty {
...
} else for item in collection {
...
}

If you're filtering while iterating, you can use an access counter, for what is 
surely an uncommon test, or better yet, filter first and use the leading 
isEmpty test:

var access = 0
for item in collection where condition {
access += 1
}
if access == 0 {
}

It seems to me that the only reason the language should change would be to 
handle abnormal loop processing, such as a break, but then why not throw an 
error and embed the for-loop in a do-catch? And honestly, I don't really think 
I'd ever use this or could think of a scenario where I'd need this.

-- E


> On Feb 3, 2017, at 10:01 AM, Thorsten Seitz via swift-evolution 
>  wrote:
> 
> I would prefer `ifNone:` instead of `otherwise` as it makes the semantics 
> clearer IMHO.
> 
> -Thorsten 
> 
> Am 03.02.2017 um 12:50 schrieb Haravikk via swift-evolution 
> >:
> 
>> 
>>> On 2 Feb 2017, at 13:44, Derrick Ho >> > wrote:
>>> 
>>> Maybe we can add a new parameter "otherwise" to the forEach method
>>> 
>>> [1,2,3,4].forEach({
>>> // do something
>>> }
>>> , otherwise: {
>>> // do something if it is an empty array
>>> })
>> 
>> That could be a decent compromise; just tried a simple extension and the 
>> following seems to work quite nicely:
>> 
>> extension Sequence {
>>  func forEach(_ body: (Iterator.Element) throws -> Void, otherwise: () 
>> throws -> Void) rethrows -> Void {
>>  var it = self.makeIterator()
>>  if let first = it.next() {
>>  try body(first)
>>  while let current = it.next() { try body(current) }
>>  } else { try otherwise() }
>>  }
>> }
>> 
>> let names = ["foo", "bar", "baz"], empty:[String] = []
>> names.forEach({ print($0) }, otherwise: { print("no names") })
>> empty.forEach({ print($0) }, otherwise: { print("no names") })
>> 
>> Of course it lacks the ability to use continue or break, so the question is; 
>> does it add enough utility to add, or is it better left to developers to 
>> extend themselves?
>> 
>>> On Thu, Feb 2, 2017 at 6:31 AM Haravikk via swift-evolution 
>>> > wrote:
>>> I'm of two minds on this feature; I kind of support the idea of the 
>>> construct, especially because there are some behind the scenes 
>>> optimisations it can do, and it can look neater.
>>> However, I'm not at all keen on the re-use of else; if there were a better 
>>> keyword I might suppose that, for example "empty" or something like that, 
>>> but nothing I can think of feels quite right.
>>> 
>>> I mean, when it comes down to it the "best" way to write the loop is like:
>>> 
>>> var it = names.makeIterator()
>>> if let first = it.next() {
>>> print(first)
>>> while let current = it.next() { print(current) }
>>> } else { print("no names") }
>>> 
>>> However this is a horrible thing to do in your own code, especially if the 
>>> loop body is larger than one line, but is just fine if it's done behind the 
>>> scenes for you (complete with unwrapping of the iterators if their type is 
>>> known).
>>> 
>>> Which is why I kind of like the idea of having the construct itself; 
>>> otherwise, like others, I use the less "correct" option like so (for 
>>> sequences):
>>> 
>>> var empty = true
>>> for name in names { print(name); empty = false }
>>> if empty { print("no names") }
>>> 
>>> At which point I simply hope that the compiler optimises away the 
>>> assignment (since it only actually does something on the first pass).
>>> 
>>> So yeah, I can see a use for it, but I'd prefer a construct other than 
>>> for/else to do it; at the very least a different keyword, as there's the 
>>> possibility we could also have a while/else as well and it would need to be 
>>> very clear, which I don't feel that for/else is.
>>> 
 On 2 Feb 2017, at 11:06, Jeremy Pereira via swift-evolution 
 > wrote:
 
> 
> On 1 Feb 2017, at 18:29, Chris Davis via swift-evolution 
> > wrote:
> 
> ah! I forgot about the break semantics, that’s definitely one for the con 
> list.
> 
> I like Nicolas’ solution, clear to read.
> 
>> On 1 Feb 2017, at 18:18, Nicolas Fezans > > wrote:
>> 
>> I tend to write this kind of treatment the other way around...
>> 
>> if names.isEmpty {
>>  // do whatever
>> } // on other cases I might have a few else-if to treat 

Re: [swift-evolution] Strings in Swift 4

[Jordan Rose via swift-evolution]

A bit late, but I agree with Ben on all of this. We could have separate 
IncompleteRange and InfiniteRange types, and have a consistent world, and even 
figure out how to get the context-less case to pick InfiniteRange. But we don’t 
have to, and I don’t think it buys us anything because—as was said—the two 
kinds of ranges are never used in the same context. There’s no overload madness.

On the specific point that `for i in 0…` behaves differently than `for elem in 
arr[0…]`, I think that’s just picking one interpretation of “arr[0…]” and then 
(legitimately) claiming it leads to nonsense. I see no problem saying that a 
subscript for an IncompleteRange, or LowerBoundedRange, or whatever gives you 
the elements starting at that index, but that trying to iterate such a range 
(when Countable) gives you unlimited iteration. I think this is more a 
theoretical concern than a practical one.

Jordan


> On Feb 1, 2017, at 10:37, Ben Cohen via swift-evolution 
>  wrote:
> 
> 
> I think Dave has already made these points separately but it probably helps 
> to recap more explicitly the behavior we expect from “x…"
> 
> Names are just for discussion purposes, exact naming can be left as a 
> separate discussion from functionality:
> 
> - Informally, one-sided ranges are a thing. Formally, there are lower-bounded 
> one-sided ranges, which are created with a postfix ... operator. For now, 
> let’s just fully understand them and come back to upper-bounded ranges later.
> - Collections will have a subscript that takes a one-sided range and returns 
> a SubSequence. The behavior of that subscript is that the collection "fills 
> in" the “missing” side with it’s upper/lower bound and uses that two-sided 
> range to return a slice.*
> - When the Bound type of a lower-bounded range is countable, it will conform 
> to Sequence.** The behavior of that sequence’s iterator is that it starts at 
> the lower bound, and increments indefinitely.
> - One-sided ranges should have ~= defined for use with switch statements, 
> where any value above the bound for a lower-bounded range would return true.
> 
> * implementation detail: collections would probably have a generic subscript 
> taking a type conforming to RangeExpression, and that protocol would have a 
> helper extension for filling in the missing range given a collection
> **one-sided ranges ought in fact to be infinite Collections… a concept that 
> needs a separate thread
> 
> With that defined:
> 
>> On Feb 1, 2017, at 5:02 AM, Xiaodi Wu via swift-evolution 
>> > wrote:
>> 
>> I entirely agree with you on the desired behavior of `zip(...)`.
>> 
>> However, if you insist on 0... being notionally an infinite range, then you 
>> would have to insist on `for i in 0...` also trapping. Which is not a big 
>> deal, IMO, but will surely make the anti-trapping crowd upset.
>> 
> 
> Certainly, for i in 0… would trap once the iterator needs to increment past 
> Int.max. If you break out of the loop before this happens, it won’t trap. The 
> statement is the moral equivalent of a C-style for(i = 0; /*nothing*/ ; ++i).
> 
> If the anti-trapping crowd are upset, they should be upset with Int, not this 
> range type. The range has no opinion on trapping – its iterator just 
> increments its Bounds type when asked to.
> 
>> The bigger issue is that either you must have a lenient/clamping subscript 
>> for `arr[0...]` or it too must trap, which is not desired. 
> 
> Based on the definition I give above, arr[0…] means “from 0 up to the 
> endIndex of arr”. This will not trap.
> 
> (there is a legitimate quibble here that this will translate into 
> arr[0.. invalid. But 0..< is ugly so we should ignore this quibble for the sake of 
> aesthetics)
> 
>> However, if `arr[0...]` is clamping, then `[1, 2, 3][100...]` would not trap 
>> and instead give you `[]`.
>> 
> 
> It should trap, because 100.. slicing this array.
> 
>> If 0... is regarded as an incomplete range, your example of `zip(...)` could 
>> still trap as desired. It would trap on the notional attempt to assign 
>> someArray.count to IncompleteRange.inferredUpperBound if count exceeds 
>> T.max. 
> 
> It’s unclear to me whether you are trying to formally define 
> .inferredUpperBound as a property you expect to exist, or if you’re using it 
> as informal shorthand. But there is no implied upper bound to a one-sided 
> lower-bounded range, only an actual lower bound. Operations taking 
> lower-bounded ranges as arguments can infer their own upper bound from 
> context, or not, depending on the functionality they need.
> 
> As an example of an alternative inferred upper bound: suppose you want to 
> define your own ordering for ranges, for sorting/display purposes. You decide 
> on a lexicographic ordering first by lower then upper bound. You want 
> one-sided ranges to 

Re: [swift-evolution] Subclass Existentials

[Douglas Gregor via swift-evolution]

> On Feb 2, 2017, at 3:24 PM, David Hart  wrote:
> 
>> 
>> On 3 Feb 2017, at 00:04, Douglas Gregor via swift-evolution 
>> > wrote:
>> 
>> 
>>> On Feb 2, 2017, at 2:54 PM, David Smith >> > wrote:
>>> 
 
 On Feb 2, 2017, at 11:20 AM, Douglas Gregor via swift-evolution 
 > wrote:
 
 
> On Feb 1, 2017, at 11:44 PM, Adrian Zubarev 
>  > wrote:
> 
> typealias AnyObject = … is nice to have, but how about if we fully drop 
> the class constraint-keyword and generalize AnyObject instead?
> 
 That’s a good point. My *technical* goal is for AnyObject to cease to be a 
 protocol, because it’s really describing something more fundamental (“it’s 
 a class!”). Whether we spell that constraint as “class” or “AnyObject” 
 doesn’t affect that technical goal.
 
 I’d gravitated toward the “class” spelling because the idea of a class 
 constraint seems most naturally described by “class”, and it’s precedented 
 in C#.
 
 However, the changes in SE-0095 
 
  to make “Any” a more fundamental type (and not just a typealias) 
 definitely open the door to doing the same thing with “AnyObject”—just 
 make it a built-in notion in the language, and the spelling for a class 
 constraint. It *certainly* works better with existentials.
 
> In the future we might want to add AnyValue with value (semantics) 
> constraint, would that mean that we’d need another keyword there like 
> value?
> 
 “value” would be a terrible keyword, as you know. Point taken :)
 
 If we did something like this, we would probably want it to be akin to 
 ValueSemantics—not just “it’s a struct or enum”, but “it provides value 
 semantics”, because not all structs/enums provide value semantics (but 
 immutable classes do).
 
> Speaking of the future directions:
> 
> Now that we’re no longer supporting the idea of Any<…> syntax and any 
> type prefixed with Any seems to be special for its particular usage, 
> could we safely bring the empty Any protocol back (is this somehow ABI 
> related?)?
> 
 From an implementation standpoint, the choice to make AnyObject a magic 
 protocol was a *horrible* decision. We have hacks throughout 
 everything—the compiler, optimizers, runtime, and so on—that specifically 
 check for the magic AnyObject protocol. So, rather than make Any a magic 
 protocol, we need to make AnyObject *not* magic.
 
> One day after this proposal is accepted, implemented and released, we 
> probably will talk about the where clause for existentials. But since a 
> lot of the existentials will have the form typealias Abc = …, this talk 
> will also include the ability to constrain generic typealiases.
> 
 By “one day” I suspect you mean “some day” rather than “the day after” :)
 
 Yes, I feel like this is a natural direction for existentials to go.
>>> 
>>> Looking ahead to when this is on the table, I'm a little worried about the 
>>> syntactic implications of constrained existentials now that the Any<> 
>>> syntax doesn't seem to be as popular. The obvious way to go would be
>>> 
>>> 'X & Y where …'
>>> 
>>> But that leads to ambiguity in function declarations
>>> 
>>> func doTheThing() -> X & Y where … where T == …
>>> 
>>> This could be resolved by requiring constrained existentials to be 
>>> typealiased to return them, but I don't think there's any other situations 
>>> where we require a typealias to use something, and it just feels like a 
>>> workaround.
>> 
>> Types can be parenthesized, so that’s a workaround. But I too have some 
>> concerns here that we’re creating an ambiguity that users will trip over.
> 
> On top of the ambiguity, I’m really sad that we dropped the Any 
> syntax because we lost the parallel to inheritance clauses which use the 
> comma as separating character. They both represent similar concepts: a type 
> inheriting and conforming and an existential represent all types which 
> inherit and conform.
> 
> I’ve got to ask, is there any chance that either of the two could happen:
> 
> 1) Bring back the Any syntax instead of A & B & C?
> 2) Replace the inheritance clause X : A, B, C to X : A & B & C?

Both are possible, as is

(3) Let A & B & C be a shortcut syntax for Any, such that Any<…> is 
the more general version that also permits where clauses, “class” constraints, 
etc.

Note that (2) would kill me ;)

> I know that both are severely source-breaking changes, but either of those 
> would simplify 

Re: [swift-evolution] for-else syntax

[Thorsten Seitz via swift-evolution]

I would prefer `ifNone:` instead of `otherwise` as it makes the semantics 
clearer IMHO.

-Thorsten 

> Am 03.02.2017 um 12:50 schrieb Haravikk via swift-evolution 
> :
> 
> 
>> On 2 Feb 2017, at 13:44, Derrick Ho  wrote:
>> 
>> Maybe we can add a new parameter "otherwise" to the forEach method
>> 
>> [1,2,3,4].forEach({
>> // do something
>> }
>> , otherwise: {
>> // do something if it is an empty array
>> })
> 
> That could be a decent compromise; just tried a simple extension and the 
> following seems to work quite nicely:
> 
> extension Sequence {
>   func forEach(_ body: (Iterator.Element) throws -> Void, otherwise: () 
> throws -> Void) rethrows -> Void {
>   var it = self.makeIterator()
>   if let first = it.next() {
>   try body(first)
>   while let current = it.next() { try body(current) }
>   } else { try otherwise() }
>   }
> }
> 
> let names = ["foo", "bar", "baz"], empty:[String] = []
> names.forEach({ print($0) }, otherwise: { print("no names") })
> empty.forEach({ print($0) }, otherwise: { print("no names") })
> 
> Of course it lacks the ability to use continue or break, so the question is; 
> does it add enough utility to add, or is it better left to developers to 
> extend themselves?
> 
>>> On Thu, Feb 2, 2017 at 6:31 AM Haravikk via swift-evolution 
>>>  wrote:
>>> I'm of two minds on this feature; I kind of support the idea of the 
>>> construct, especially because there are some behind the scenes 
>>> optimisations it can do, and it can look neater.
>>> However, I'm not at all keen on the re-use of else; if there were a better 
>>> keyword I might suppose that, for example "empty" or something like that, 
>>> but nothing I can think of feels quite right.
>>> 
>>> I mean, when it comes down to it the "best" way to write the loop is like:
>>> 
>>> var it = names.makeIterator()
>>> if let first = it.next() {
>>> print(first)
>>> while let current = it.next() { print(current) }
>>> } else { print("no names") }
>>> 
>>> However this is a horrible thing to do in your own code, especially if the 
>>> loop body is larger than one line, but is just fine if it's done behind the 
>>> scenes for you (complete with unwrapping of the iterators if their type is 
>>> known).
>>> 
>>> Which is why I kind of like the idea of having the construct itself; 
>>> otherwise, like others, I use the less "correct" option like so (for 
>>> sequences):
>>> 
>>> var empty = true
>>> for name in names { print(name); empty = false }
>>> if empty { print("no names") }
>>> 
>>> At which point I simply hope that the compiler optimises away the 
>>> assignment (since it only actually does something on the first pass).
>>> 
>>> So yeah, I can see a use for it, but I'd prefer a construct other than 
>>> for/else to do it; at the very least a different keyword, as there's the 
>>> possibility we could also have a while/else as well and it would need to be 
>>> very clear, which I don't feel that for/else is.
>>> 
> On 2 Feb 2017, at 11:06, Jeremy Pereira via swift-evolution 
>  wrote:
> 
> 
> On 1 Feb 2017, at 18:29, Chris Davis via swift-evolution 
>  wrote:
> 
> ah! I forgot about the break semantics, that’s definitely one for the con 
> list.
> 
> I like Nicolas’ solution, clear to read.
> 
>> On 1 Feb 2017, at 18:18, Nicolas Fezans  wrote:
>> 
>> I tend to write this kind of treatment the other way around...
>> 
>> if names.isEmpty {
>>  // do whatever
>> } // on other cases I might have a few else-if to treat other cases that 
>> need special treament
>> else {
>>  for name in names {
>>  // do your thing
>>  }
>> }
 
 
 This only works if you know the size of the sequence before you start 
 iterating it. You can, for example, iterate a lazy sequence and 
 calculating its size before iterating it defeats the object.Thus for { … } 
 else { … } where the else block only executes if the for block was never 
 executed does have some utility.
 
 However, I am not in favour adding it. The same functionality can be 
 achieved by counting the number of iterations and testing the count 
 afterwards (or by using a boolean). It takes a couple of extra lines of 
 code and an extra variable, but I think that is a Good Thing. It’s more 
 explicit and (as the Python example shows) there could be hidden 
 subtleties that confuse people if for … else … is badly designed. Also, in 
 many cases, I would argue that treating the zero element sequence 
 differently to the n > 0 element sequence is a code smell. About the only 
 use-case I can think of off the top of my head is UI presentation e.g. 
 “your search didn’t 

Re: [swift-evolution] Proposal seed: gathering data to fix the NSUInteger inconsistency

[Karl Wagner via swift-evolution]

> On 2 Feb 2017, at 02:29, Jordan Rose via swift-evolution 
>  wrote:
> 
> For people who would suggest that Swift actually take unsigned integers 
> seriously instead of using ‘Int’ everywhere, I sympathize, but I think that 
> ship has sailed—not with us, but with all the existing UIKit code that uses 
> NSInteger for counters. Consistently importing NSUInteger as UInt would be a 
> massive source-break in Swift 4 that just wouldn’t be worth it. Given that, 
> is it better to more closely model what’s in user headers, or to have 
> consistency between user and system headers?
> 

I’ve always considered our handling of signed/unsigned numbers a huge 
deficiency of Swift.

I appreciate that NSNotFound makes things difficult, but at the same time, 
eliminating these sentinel values is one of the big benefits for Obj-C 
developers of moving to Swift. It’s a bit disheartening that Apple’s own 
frameworks can’t use that. I wonder if the better answer wouldn’t be to 
introduce an analogue of Optional to Objective-C and supplement the 
signed-with-sentinel methods with optional-unsigned ones, which we would prefer 
when importing. 3rd-party code could migrate to that new type so that they can 
be imported in to Swift without sentinels.

That could cause source-breakage for Swift code, but I remember that members of 
the core-team have said several times that they would like some kind of safe 
mixed-type arithmetic and comparison to become part of the language one day. I 
feel that that is ultimately the better way to go in the long-run. I’ve always 
found it strange that Swift often promotes safety over convenience (e.g. 
exhaustive switches, trapping on overflow), but then in this one case takes the 
exact opposite approach.

Since I’m on the subject, I’d also support Array’s index becoming a UInt and 
all of its index-related methods becoming generic to take any kind of integer. 
Or, to put it another way, if we could make Array.Index == Any 
(an existential), so you could feed indexes in and pull them out in whichever 
integer type you need — after all, the exact type of the index is not 
necessarily fundamental to what an Array represents; all that matters is that 
it’s elements have a contiguous space of integrally-advancing offsets.

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

Re: [swift-evolution] for-else syntax

[Haravikk via swift-evolution]

> On 2 Feb 2017, at 13:44, Derrick Ho  wrote:
> 
> Maybe we can add a new parameter "otherwise" to the forEach method
> 
> [1,2,3,4].forEach({
> // do something
> }
> , otherwise: {
> // do something if it is an empty array
> })

That could be a decent compromise; just tried a simple extension and the 
following seems to work quite nicely:

extension Sequence {
func forEach(_ body: (Iterator.Element) throws -> Void, otherwise: () 
throws -> Void) rethrows -> Void {
var it = self.makeIterator()
if let first = it.next() {
try body(first)
while let current = it.next() { try body(current) }
} else { try otherwise() }
}
}

let names = ["foo", "bar", "baz"], empty:[String] = []
names.forEach({ print($0) }, otherwise: { print("no names") })
empty.forEach({ print($0) }, otherwise: { print("no names") })

Of course it lacks the ability to use continue or break, so the question is; 
does it add enough utility to add, or is it better left to developers to extend 
themselves?

> On Thu, Feb 2, 2017 at 6:31 AM Haravikk via swift-evolution 
> > wrote:
> I'm of two minds on this feature; I kind of support the idea of the 
> construct, especially because there are some behind the scenes optimisations 
> it can do, and it can look neater.
> However, I'm not at all keen on the re-use of else; if there were a better 
> keyword I might suppose that, for example "empty" or something like that, but 
> nothing I can think of feels quite right.
> 
> I mean, when it comes down to it the "best" way to write the loop is like:
> 
> var it = names.makeIterator()
> if let first = it.next() {
>   print(first)
>   while let current = it.next() { print(current) }
> } else { print("no names") }
> 
> However this is a horrible thing to do in your own code, especially if the 
> loop body is larger than one line, but is just fine if it's done behind the 
> scenes for you (complete with unwrapping of the iterators if their type is 
> known).
> 
> Which is why I kind of like the idea of having the construct itself; 
> otherwise, like others, I use the less "correct" option like so (for 
> sequences):
> 
> var empty = true
> for name in names { print(name); empty = false }
> if empty { print("no names") }
> 
> At which point I simply hope that the compiler optimises away the assignment 
> (since it only actually does something on the first pass).
> 
> So yeah, I can see a use for it, but I'd prefer a construct other than 
> for/else to do it; at the very least a different keyword, as there's the 
> possibility we could also have a while/else as well and it would need to be 
> very clear, which I don't feel that for/else is.
> 
>> On 2 Feb 2017, at 11:06, Jeremy Pereira via swift-evolution 
>> > wrote:
>> 
>>> 
>>> On 1 Feb 2017, at 18:29, Chris Davis via swift-evolution 
>>> > wrote:
>>> 
>>> ah! I forgot about the break semantics, that’s definitely one for the con 
>>> list.
>>> 
>>> I like Nicolas’ solution, clear to read.
>>> 
 On 1 Feb 2017, at 18:18, Nicolas Fezans > wrote:
 
 I tend to write this kind of treatment the other way around...
 
 if names.isEmpty {
// do whatever
 } // on other cases I might have a few else-if to treat other cases that 
 need special treament
 else {
for name in names {
// do your thing
}
 }
 
>> 
>> 
>> This only works if you know the size of the sequence before you start 
>> iterating it. You can, for example, iterate a lazy sequence and calculating 
>> its size before iterating it defeats the object.Thus for { … } else { … } 
>> where the else block only executes if the for block was never executed does 
>> have some utility.
>> 
>> However, I am not in favour adding it. The same functionality can be 
>> achieved by counting the number of iterations and testing the count 
>> afterwards (or by using a boolean). It takes a couple of extra lines of code 
>> and an extra variable, but I think that is a Good Thing. It’s more explicit 
>> and (as the Python example shows) there could be hidden subtleties that 
>> confuse people if for … else … is badly designed. Also, in many cases, I 
>> would argue that treating the zero element sequence differently to the n > 0 
>> element sequence is a code smell. About the only use-case I can think of off 
>> the top of my head is UI presentation e.g. “your search didn’t return any 
>> results” instead of a blank page.
>> 
>> Talking of Python, Swift is not Python and the argument not to implement a 
>> feature because its semantics conflict with the semantics of a similar 
>> looking feature in another language is 

Re: [swift-evolution] [Discussion] mailing list alternative

[Jeremy Pereira via swift-evolution]

I’m not a fan of moving to a forum or equivalent, however, I’m coming round to 
the idea. I’d be fine with it as long as the following features were included:

* configurable so that I am emailed all new topics and new posts (or RSS 
equivalent)

* Support for markdown, ideally the GitHub dialect

* moderation for off topic posts and spam

From my brief scan of their web site, Discourse seems to fit the bill but it 
does talk about threads being a single dynamically loaded page rather than 
multiple pages. How well does that work when a thread has a thousand posts in 
it?
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] for-else syntax

[Jeremy Pereira via swift-evolution]

> On 3 Feb 2017, at 09:27, Dimitri Racordon via swift-evolution 
>  wrote:
> 
>> Talking of Python, Swift is not Python and the argument not to implement a 
>> feature because its semantics conflict with the semantics of a similar 
>> looking feature in another language is bogus. I don’t see the Python for … 
>> else being different (and having looked it up to see what you all were 
>> talking about, my opinion is that the Python for … else is a disaster) as 
>> being a legitimate con to this cleaner and more logical idea in Swift.
> 
> Swift is not Python, but Python programmers do program in Swift. Yeah they 
> can look up the documentation and see that the semantics is not the same, but 
> that is definitely error-prone.

I have to say "so what”? You move from one language to another, there are 
points of confusion. There is no legitimate argument that says Swift should not 
implement a feature because it would confuse Python programmers (or programmers 
in any other language). If there were, Swift wouldn’t exist, we would just have 
a new Python-Coocoa bridge.

> 
> While this kind of construct happen quite often, I am not for changing the 
> syntax of a for-loop. To be honest, I don’t think that "for { .. } else { .. 
> }” is so clear intuitive and I think that I would choose most if not all of 
> the other constructions that have been proposed to express the OP’s problem.

That is my position too. There are (persuasive IMO) arguments to say let’s not 
do this. My rant above was just to say “different to language X and therefore 
confusing to language X programmers” is not one of them.


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

Re: [swift-evolution] [Discussion] mailing list alternative

[Muse M via swift-evolution]

One feature is I need the ability to bookmark where I stop reading
during the journey or trip.

A few contributors keep replying with quoted message ate up my mobile data
usage significantly especially this thread is getting a long discussion is
hard to read on a small screen and I don't use email clients on iPhone.

Forum is useful when we need share photos and video.


On Friday, February 3, 2017, Muse M  wrote:

> One feature is I need the ability to bookmark where I stop reading
> during the journey or trip.
>
> A few contributors keep replying with quoted message ate up my mobile data
> usage significantly especially this thread is getting a long discussion is
> hard to read on a small screen and I don't use email clients on iPhone.
>
> Forum is useful when we need share photos and video.
>
> On Friday, February 3, 2017, Tino Heth via swift-evolution <
> swift-evolution@swift.org
> > wrote:
>
>>
>> In a mailing list format, everyone is free to start a new thread.
>>
>> Would a forum have a privilege system that stops newbies from starting
>> threads? I've seen no one proposing that.
>>
>>
>> Whether you invented the language or started learning it yesterday, if
>> you have a new idea, it comes into everyone's inbox in exactly the same
>> way. No one's user name has extra flares or trophies or whatever reminding
>> you of their status.
>>
>>
>> Imho that's just wrong, and this message somewhat proves my point:
>> There are several users with a "@apple.com" trophy, and I guess most
>> people who spend a significant amount of time on swift-evolution also have
>> developed a preference not only for topics, but also for authors (saving
>> matching posts from being ignored).
>>
>> The ability to "like" posts would be a remarkable help for newbies to
>> gather attention for their ideas — not because of the status of the author,
>> but because of the quality of their contribution.
>>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] for-else syntax

[Dimitri Racordon via swift-evolution]

Talking of Python, Swift is not Python and the argument not to implement a 
feature because its semantics conflict with the semantics of a similar looking 
feature in another language is bogus. I don’t see the Python for … else being 
different (and having looked it up to see what you all were talking about, my 
opinion is that the Python for … else is a disaster) as being a legitimate con 
to this cleaner and more logical idea in Swift.

Swift is not Python, but Python programmers do program in Swift. Yeah they can 
look up the documentation and see that the semantics is not the same, but that 
is definitely error-prone.

While this kind of construct happen quite often, I am not for changing the 
syntax of a for-loop. To be honest, I don’t think that "for { .. } else { .. }” 
is so clear intuitive and I think that I would choose most if not all of the 
other constructions that have been proposed to express the OP’s problem.

Maybe we can add a new parameter "otherwise" to the forEach method

[1,2,3,4].forEach({
// do something
}
, otherwise: {
// do something if it is an empty array
})

The problem with this approach is that it would prevent the body of the 
for-loop to be expressed with a trailing closure.

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

Re: [swift-evolution] [Discussion] mailing list alternative

[Tino Heth via swift-evolution]

> In a mailing list format, everyone is free to start a new thread.
Would a forum have a privilege system that stops newbies from starting threads? 
I've seen no one proposing that.


> Whether you invented the language or started learning it yesterday, if you 
> have a new idea, it comes into everyone's inbox in exactly the same way. No 
> one's user name has extra flares or trophies or whatever reminding you of 
> their status.

Imho that's just wrong, and this message somewhat proves my point:
There are several users with a "@apple.com" trophy, and I guess most people who 
spend a significant amount of time on swift-evolution also have developed a 
preference not only for topics, but also for authors (saving matching posts 
from being ignored).

The ability to "like" posts would be a remarkable help for newbies to gather 
attention for their ideas — not because of the status of the author, but 
because of the quality of their contribution.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution