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

[Ted kremenek via swift-evolution]

> On Feb 2, 2017, at 9:56 PM, Erica Sadun  wrote:
> 
> 
>> On Feb 2, 2017, at 10:29 PM, Ted kremenek  wrote:
>> 
>> 
>> 
>> On Feb 2, 2017, at 6:36 PM, Karl Wagner  wrote:
>> 
>>> 
 On 3 Feb 2017, at 02:55, Ted kremenek  wrote:
 
 
 
> On Feb 2, 2017, at 12:58 PM, Karl Wagner via swift-evolution 
>  wrote:
> 
> Personally I think that's an absurd reason not to move to a forum. What 
> is your complaint? That it's _too_ inclusive? That others only have 
> trivial things to say? Frankly, every way I try to interpret your comment 
> makes it come off as snobbery.
 
 Hi Karl,
 
 I appreciate your candor here, but let's avoid making these comments sound 
 personal.  This is a thread prompting polarized opinions, and most of it 
 has been civil and productive.  Let's keep it that way.  I do respect that 
 you are anxious to see progress on the resolution of the topic, but these 
 same points could be made in a less antagonistic way.
 
 I encourage all of you to re-read this part of the Code of Conduction on 
 Swift.org:
 
> Examples of unacceptable behavior by participants include:
> 
> The use of sexualized language or imagery
> Personal attacks
> Trolling or insulting/derogatory comments
> Public or private harassment
> Publishing other’s private information, such as physical or electronic 
> addresses, without explicit permission
> Other unethical or unprofessional conduct
> Project maintainers have the right and responsibility to remove, edit, or 
> reject comments, commits, code, wiki edits, issues, and other 
> contributions that are not aligned to this Code of Conduct, or to ban 
> temporarily or permanently any contributor for other behaviors that they 
> deem inappropriate, threatening, offensive, or harmful.
> 
 Thank you,
 Ted
 
>>> 
>>> As I explained to Erica, it isn’t meant to be read personally. What I said 
>>> is that the community should be as inclusive as possible and that 
>>> prejudicing certain opinions as “trivial” conceptually runs against that.
>> 
>> I appreciate that perspective — and I personally agree with that point.  My 
>> cautionary statement — which was also directed at others on the thread — was 
>> to ensure that the thread remains amicable, and that our choice of our words 
>> match our intentions as the arguments become potentially polarized.
> 
> "Trivial" describes the briefness of the response and  *not* the quality of 
> opinions. Quick back and forth comments that fit well on forums can produce 
> an explosion of emails. Moving to a forum that supports email mirroring does 
> not produce the same experience for those using mail clients. 
> 
> -- E

I agree with you that moving to a forum that supports email mirroring will not 
produce the same experience for those using mail clients.  The question to me 
is not whether they are different, but what impact that difference will have in 
practice — and whether that difference, even if it is slightly negative, is the 
right tradeoff.  Some of that is hard to predict, as it comes down somewhat to 
how participation on a swift-evolution forum would be in practice.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

> On Feb 2, 2017, at 10:29 PM, Ted kremenek  wrote:
> 
> 
> 
> On Feb 2, 2017, at 6:36 PM, Karl Wagner  > wrote:
> 
>> 
>>> On 3 Feb 2017, at 02:55, Ted kremenek >> > wrote:
>>> 
>>> 
>>> 
>>> On Feb 2, 2017, at 12:58 PM, Karl Wagner via swift-evolution 
>>> > wrote:
>>> 
 Personally I think that's an absurd reason not to move to a forum. What is 
 your complaint? That it's _too_ inclusive? That others only have trivial 
 things to say? Frankly, every way I try to interpret your comment makes it 
 come off as snobbery.
>>> 
>>> Hi Karl,
>>> 
>>> I appreciate your candor here, but let's avoid making these comments sound 
>>> personal.  This is a thread prompting polarized opinions, and most of it 
>>> has been civil and productive.  Let's keep it that way.  I do respect that 
>>> you are anxious to see progress on the resolution of the topic, but these 
>>> same points could be made in a less antagonistic way.
>>> 
>>> I encourage all of you to re-read this part of the Code of Conduction on 
>>> Swift.org :
>>> 
 Examples of unacceptable behavior by participants include:
 
 The use of sexualized language or imagery
 Personal attacks
 Trolling or insulting/derogatory comments
 Public or private harassment
 Publishing other’s private information, such as physical or electronic 
 addresses, without explicit permission
 Other unethical or unprofessional conduct
 Project maintainers have the right and responsibility to remove, edit, or 
 reject comments, commits, code, wiki edits, issues, and other 
 contributions that are not aligned to this Code of Conduct, or to ban 
 temporarily or permanently any contributor for other behaviors that they 
 deem inappropriate, threatening, offensive, or harmful.
 
>>> Thank you,
>>> Ted
>>> 
>> 
>> As I explained to Erica, it isn’t meant to be read personally. What I said 
>> is that the community should be as inclusive as possible and that 
>> prejudicing certain opinions as “trivial” conceptually runs against that.
> 
> I appreciate that perspective — and I personally agree with that point.  My 
> cautionary statement — which was also directed at others on the thread — was 
> to ensure that the thread remains amicable, and that our choice of our words 
> match our intentions as the arguments become potentially polarized.

"Trivial" describes the briefness of the response and  *not* the quality of 
opinions. Quick back and forth comments that fit well on forums can produce an 
explosion of emails. Moving to a forum that supports email mirroring does not 
produce the same experience for those using mail clients. 

-- E


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

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

[Ted kremenek via swift-evolution]

> On Feb 2, 2017, at 7:23 PM, Xiaodi Wu  wrote:
> 
> Great, but let's continue discussing what the needs and aspirations of the 
> community are and what our non-goals are, then study what platforms best fit 
> those. It sure sounds nice that Discourse can be set up as a mailing list, 
> and that it can have extra voting dingbats or none at all, etc., etc. But in 
> deciding what platform we should use it helps not to lose sight of what kind 
> of a community we want to promote. Articulate those and gain some consensus, 
> and after that the process of comparing product feature lists will surely be 
> the easy part.

I agree — which should pick the tool that matches with community we want to 
promote.

For me I feel that swift-evolution has an established ethos that works well, 
and I would not want to see that go away in a forum.  My hope is a forum allows 
more people to sporadically participate on topics that are of interest to them. 
 I also feel that a forum provides some standard affordances — e.g., Markdown — 
that can be helpful in technical discussions.

Here are the factors I am evaluating:

1. Preserves/encourages the community discussions we want — which ties in with 
the points you made about the nature of the community we want.

2. Make discussions more accessible to members of the community who want to use 
their valuable time to participate in discussions that are important to them, 
but not necessarily need to pay a high cost in participating in all discussions.

3. Ideally not degrade the experience for those participating on 
swift-evolution all the time and are monitoring all (or the majority) of 
traffic.  This is the main concern from people who like the mailing lists.

4. Affordances for searching through topics, cross-referencing, etc.  This is 
very useful for relating similar but disjoint topics.

5. Better tools for authoring content, such as using Markdown (especially for 
writing out code).

6. Privacy — not everyone wants to share their email or create a new one just 
to participate not he evolution threads.  This ties in with #2.

The other thing — which has not been discussed very much — is whether or not if 
we move to a forum to move ALL of the lists to a forum, or just 
swift-evolution.  My preference if we moved to forums would be to go all in, 
but discussion should happen on those lists as well (e.g., swift-dev).


>> On Thu, Feb 2, 2017 at 20:59 Jacob Bandes-Storch  wrote:
>> On Thu, Feb 2, 2017 at 6:37 PM, Xiaodi Wu via swift-evolution 
>>  wrote:
>> On Thu, Feb 2, 2017 at 8:03 PM, Ted kremenek via swift-evolution 
>>  wrote:
>> 
>> 
>>> On Feb 2, 2017, at 5:35 PM, Karl Wagner via swift-evolution 
>>>  wrote:
>>> 
>>> It's at least worth a beta test.
>> 
>> There are real concerns to work out here — just moving to the forum blindly 
>> would be bad if it is highly disruptive to the community having important 
>> discussions.  I DO think a forum is likely the way to go, but I also am not 
>> dismissive that individuals who are highly active on swift-evolution that 
>> prefer an email workflow will not have their own participation significantly 
>> compromised by just moving to a forum in a cavalier way.
>> 
>> What I have enjoyed seeing from this thread is a healthy discussion about 
>> tradeoffs of both approaches and an identification of concerns of moving 
>> away from the mailing lists.  Some responses to those concerns have been 
>> "Discourse can handle that", which to me is part of the evaluation of the 
>> tradeoffs.  I am also really happy that Nate setup the mock Discourse setup 
>> so we could evaluate thing like the email bridge.  For example, 
>> experimenting of whether or not a rich HTML email works versus plain text 
>> emails for inline responses (which turns out to have problems), etc.   
>> That's all super useful for actually evaluating moving to Discourse, so in 
>> my mind we are actually trying things out and identifying problem points.
>> 
>> The other thing I'm considering is the practical logistics of getting this 
>> set up and maintained (from an infrastructure perspective).  That's not 
>> something that needs to be discussed on this thread — I'd rather the thread 
>> focus on whether a forum is the right thing for the community.  But it is 
>> still something that is being considered in tandem to this discussion, which 
>> obviously needs to be figured out before we just jump to using Discourse (if 
>> that is what we end up doing).
>> 
>> On the topic of whether a forum is the right thing for the community, I 
>> figure I should throw another point into the conversation. Forums are often 
>> designed around a rewards system to encourage participation in approved 
>> ways, and to encourage it frequently. People who write popular posts get 
>> more likes, or stars, or dingbats, and voting is encouraged from the 
>> 

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

[Ted kremenek via swift-evolution]

> On Feb 2, 2017, at 6:37 PM, Xiaodi Wu  wrote:
> 
>> On Thu, Feb 2, 2017 at 8:03 PM, Ted kremenek via swift-evolution 
>>  wrote:
>> 
>> 
>>> On Feb 2, 2017, at 5:35 PM, Karl Wagner via swift-evolution 
>>>  wrote:
>>> 
>>> It's at least worth a beta test.
>> 
>> There are real concerns to work out here — just moving to the forum blindly 
>> would be bad if it is highly disruptive to the community having important 
>> discussions.  I DO think a forum is likely the way to go, but I also am not 
>> dismissive that individuals who are highly active on swift-evolution that 
>> prefer an email workflow will not have their own participation significantly 
>> compromised by just moving to a forum in a cavalier way.
>> 
>> What I have enjoyed seeing from this thread is a healthy discussion about 
>> tradeoffs of both approaches and an identification of concerns of moving 
>> away from the mailing lists.  Some responses to those concerns have been 
>> "Discourse can handle that", which to me is part of the evaluation of the 
>> tradeoffs.  I am also really happy that Nate setup the mock Discourse setup 
>> so we could evaluate thing like the email bridge.  For example, 
>> experimenting of whether or not a rich HTML email works versus plain text 
>> emails for inline responses (which turns out to have problems), etc.   
>> That's all super useful for actually evaluating moving to Discourse, so in 
>> my mind we are actually trying things out and identifying problem points.
>> 
>> The other thing I'm considering is the practical logistics of getting this 
>> set up and maintained (from an infrastructure perspective).  That's not 
>> something that needs to be discussed on this thread — I'd rather the thread 
>> focus on whether a forum is the right thing for the community.  But it is 
>> still something that is being considered in tandem to this discussion, which 
>> obviously needs to be figured out before we just jump to using Discourse (if 
>> that is what we end up doing).
> 
> On the topic of whether a forum is the right thing for the community, I 
> figure I should throw another point into the conversation. Forums are often 
> designed around a rewards system to encourage participation in approved ways, 
> and to encourage it frequently. People who write popular posts get more 
> likes, or stars, or dingbats, and voting is encouraged from the community to 
> surface the most liked/starred/dingbatted. Just earlier in this thread, there 
> were explicit calls for any adopted platform to have liking/unliking features.
> 
> In a mailing list format, everyone is free to start a new thread. 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. 
> Yes, it's true that there have been a proliferation of +1's lately. It is 
> also true that not too long ago community members reminded each other not to 
> do that. The mantra, if I recall, was that it wasn't about soliciting upvotes 
> or downvotes, but rather about posting thoughtful critiques, new takes on the 
> the idea, alternative designs, etc.
> 
> So I guess I'd sum up the point as this: in the current setup, everyone's 
> message is treated equally (unless it exceeds the max email size limit, ugh); 
> in a forum, everyone's likes are treated equally. Are we unsatisfied with the 
> current community ethos? Do we want the evolution process to be about what 
> ideas garnered the most votes and whose thoughts are most popular?

These are really interesting points.  From my perspective, I'm not quite so 
concerned about this because of how I have witnessed the evolution process 
working in practice.  Everyone's message is not treated equally — instead they 
are evaluated based on the quality of their substance.  When arguments for or 
against evolution proposals get evaluated — and eventually arbitrated into a 
decision — it is rarely a strict popularity contest for an idea, but rather a 
balancing of the arguments made.  Essentially your comment about "thoughtful 
critiques", which ultimately I think provides the most meaningful guidance 
towards reaching decisions on language changes.  That's not to say that a ton 
of +1's on an argument doesn't have signal — but I'd never like to see that 
become a direct "vote".







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

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

[Ted kremenek via swift-evolution]

> On Feb 2, 2017, at 6:36 PM, Karl Wagner  wrote:
> 
> 
>> On 3 Feb 2017, at 02:55, Ted kremenek  wrote:
>> 
>> 
>> 
>>> On Feb 2, 2017, at 12:58 PM, Karl Wagner via swift-evolution 
>>>  wrote:
>>> 
>>> Personally I think that's an absurd reason not to move to a forum. What is 
>>> your complaint? That it's _too_ inclusive? That others only have trivial 
>>> things to say? Frankly, every way I try to interpret your comment makes it 
>>> come off as snobbery.
>> 
>> Hi Karl,
>> 
>> I appreciate your candor here, but let's avoid making these comments sound 
>> personal.  This is a thread prompting polarized opinions, and most of it has 
>> been civil and productive.  Let's keep it that way.  I do respect that you 
>> are anxious to see progress on the resolution of the topic, but these same 
>> points could be made in a less antagonistic way.
>> 
>> I encourage all of you to re-read this part of the Code of Conduction on 
>> Swift.org:
>> 
>>> Examples of unacceptable behavior by participants include:
>>> 
>>> The use of sexualized language or imagery
>>> Personal attacks
>>> Trolling or insulting/derogatory comments
>>> Public or private harassment
>>> Publishing other’s private information, such as physical or electronic 
>>> addresses, without explicit permission
>>> Other unethical or unprofessional conduct
>>> Project maintainers have the right and responsibility to remove, edit, or 
>>> reject comments, commits, code, wiki edits, issues, and other contributions 
>>> that are not aligned to this Code of Conduct, or to ban temporarily or 
>>> permanently any contributor for other behaviors that they deem 
>>> inappropriate, threatening, offensive, or harmful.
>>> 
>> Thank you,
>> Ted
>> 
> 
> As I explained to Erica, it isn’t meant to be read personally. What I said is 
> that the community should be as inclusive as possible and that prejudicing 
> certain opinions as “trivial” conceptually runs against that.

I appreciate that perspective — and I personally agree with that point.  My 
cautionary statement — which was also directed at others on the thread — was to 
ensure that the thread remains amicable, and that our choice of our words match 
our intentions as the arguments become potentially polarized.

> 
> That’s also my reply to the opinion others have shared that subscribing and 
> publishing your email address is a kind of “good pain” to filter out the 
> weak. Take the String model for example - isn’t it possible that this one 
> particular discussion is critical to my business, and that I don’t really 
> care about “for-else syntax” or “Annotation of Warnings/Errors” or “Compound 
> Names for Enum Cases”? I don’t see the logic which says that if I care very 
> much about one aspect of the language, I must care equally about everything 
> else that ever changes with it.

I agree with this point, and I'll be honest that I am not concerned about the 
forums being flooded with noise just because we removed friction for more 
people to participate.  The swift-evolution participants have established a 
timbre for its discussions already that I don't see fundamentally changing if 
we move to a forum.

> 
> I don’t understand why some feel it is so important to discourage ad-hoc 
> contributions. Open-source lives off ad-hoc.

For me, removing some of the friction for participation is one of the most 
appealing aspects of a forum.

___
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 2, 2017, at 9:46 PM, Chris Lattner via swift-evolution 
>  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.
> 
> -Chris

https://gist.github.com/erica/2b2d92e6db787d001c689d3e37a7c3f2 


This could easily be adapted to incorporate both the removal of enumerated as 
well as the addition of indexed, and I love the idea of using Ben's list as a 
template for the justification section, plus adding the feedback from this 
thread.

-- E


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

Re: [swift-evolution] Removing enumerated?

[Chris Lattner via swift-evolution]

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.

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

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

[Zach Drayer via swift-evolution]

hi

sorry about this message just now, i realize the tone comes across a bit short 
to say the least. buttons were mashed incorrectly and far too soon.

again, my apologies.

-z

(sent from my phone) 

> On Feb 2, 2017, at 8:12 PM, Zach Drayer  wrote:
> 
> 
> 
> 
> 
> (sent from my phone)
> 
>> On Feb 2, 2017, at 3:15 PM, James Berry via swift-evolution 
>>  wrote:
>> 
>> 
>>> On Feb 2, 2017, at 2:44 PM, Nevin Brackett-Rozinsky via swift-evolution 
>>>  wrote:
>>> 
>>> Where do you propose to hold and publicize such a vote in order that the 
>>> people who would participate on a forum but not on a mailing list―ie. those 
>>> for whom the switch will be most beneficial―are enfranchised?
>> 
>> The traditional method on a list like this is +1 or -1 in response to a 
>> given thread. (Note that I’m not calling for such a vote, as I have nothing 
>> to propose). A perhaps more modern approach would be to give a link to an 
>> external site that would run the vote/poll.
>> 
>> As to your question of how to reach an audience larger than what we have now 
>> for a vote, I don’t see any obvious solution: the current community is what 
>> it is. And I would argue that the current community has invested the most 
>> time into the project (and likely will going forward) and should have the 
>> largest vote for how project communication should be facilitated.
> I don't know if the idea that knowing how to use/being comfortable with using 
> a mailing list somehow means your input more valuable than that of someone 
> else is one that I'm comfortable with.
> 
>> I wouldn’t advocate for advertising far and wide over the internet “how 
>> should the swift-evolution community communicate?”, as this would be a vote 
>> of the internet, and not of the swift-evolution community.
> The entire purpose of this discussion is about how best to open 
> swift-evolution up to more people. Why would we ignore input from people who 
> may otherwise be involved?
> 
> 
>> I do admit you could argue the community may have already self-selected to 
>> some degree based on the current method of commutation; I see no real 
>> solution to that apart from continued advocacy from people such as you who 
>> are speaking up to bring awareness about the issues you feel are keeping 
>> outsiders from participating.
> We could try asking people in some non-mailing-list fashion?
> 
> -z
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Zach Drayer via swift-evolution]

(sent from my phone)

> On Feb 2, 2017, at 3:15 PM, James Berry via swift-evolution 
>  wrote:
> 
> 
>> On Feb 2, 2017, at 2:44 PM, Nevin Brackett-Rozinsky via swift-evolution 
>>  wrote:
>> 
>> Where do you propose to hold and publicize such a vote in order that the 
>> people who would participate on a forum but not on a mailing list―ie. those 
>> for whom the switch will be most beneficial―are enfranchised?
> 
> The traditional method on a list like this is +1 or -1 in response to a given 
> thread. (Note that I’m not calling for such a vote, as I have nothing to 
> propose). A perhaps more modern approach would be to give a link to an 
> external site that would run the vote/poll.
> 
> As to your question of how to reach an audience larger than what we have now 
> for a vote, I don’t see any obvious solution: the current community is what 
> it is. And I would argue that the current community has invested the most 
> time into the project (and likely will going forward) and should have the 
> largest vote for how project communication should be facilitated.
I don't know if the idea that knowing how to use/being comfortable with using a 
mailing list somehow means your input more valuable than that of someone else 
is one that I'm comfortable with.

> I wouldn’t advocate for advertising far and wide over the internet “how 
> should the swift-evolution community communicate?”, as this would be a vote 
> of the internet, and not of the swift-evolution community.
The entire purpose of this discussion is about how best to open swift-evolution 
up to more people. Why would we ignore input from people who may otherwise be 
involved?


> I do admit you could argue the community may have already self-selected to 
> some degree based on the current method of commutation; I see no real 
> solution to that apart from continued advocacy from people such as you who 
> are speaking up to bring awareness about the issues you feel are keeping 
> outsiders from participating.
We could try asking people in some non-mailing-list fashion?

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

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

[Xiaodi Wu via swift-evolution]

Great, but let's continue discussing what the needs and aspirations of the
community are and what our non-goals are, then study what platforms best
fit those. It sure sounds nice that Discourse can be set up as a mailing
list, and that it can have extra voting dingbats or none at all, etc., etc.
But in deciding what platform we should use it helps not to lose sight of
what kind of a community we want to promote. Articulate those and gain some
consensus, and after that the process of comparing product feature lists
will surely be the easy part.
On Thu, Feb 2, 2017 at 20:59 Jacob Bandes-Storch  wrote:

> On Thu, Feb 2, 2017 at 6:37 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On Thu, Feb 2, 2017 at 8:03 PM, Ted kremenek via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
>
> On Feb 2, 2017, at 5:35 PM, Karl Wagner via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> It's at least worth a beta test.
>
>
> There are real concerns to work out here — just moving to the forum
> blindly would be bad if it is highly disruptive to the community having
> important discussions.  I DO think a forum is likely the way to go, but I
> also am not dismissive that individuals who are highly active on
> swift-evolution that prefer an email workflow will not have their own
> participation significantly compromised by just moving to a forum in a
> cavalier way.
>
> What I have enjoyed seeing from this thread is a healthy discussion about
> tradeoffs of both approaches and an identification of concerns of moving
> away from the mailing lists.  Some responses to those concerns have been
> "Discourse can handle that", which to me is part of the evaluation of the
> tradeoffs.  I am also really happy that Nate setup the mock Discourse setup
> so we *could* evaluate thing like the email bridge.  For example,
> experimenting of whether or not a rich HTML email works versus plain text
> emails for inline responses (which turns out to have problems), etc.
> That's all super useful for actually evaluating moving to Discourse, so in
> my mind we are actually trying things out and identifying problem points.
>
> The other thing I'm considering is the practical logistics of getting this
> set up and maintained (from an infrastructure perspective).  That's not
> something that needs to be discussed on this thread — I'd rather the thread
> focus on whether a forum is the right thing for the community.  But it is
> still something that is being considered in tandem to this discussion,
> which obviously needs to be figured out before we just jump to using
> Discourse (if that is what we end up doing).
>
>
> On the topic of whether a forum is the right thing for the community, I
> figure I should throw another point into the conversation. Forums are often
> designed around a rewards system to encourage participation in approved
> ways, and to encourage it frequently. People who write popular posts get
> more likes, or stars, or dingbats, and voting is encouraged from the
> community to surface the most liked/starred/dingbatted. Just earlier in
> this thread, there were explicit calls for any adopted platform to have
> liking/unliking features.
>
> In a mailing list format, everyone is free to start a new thread. 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. Yes, it's true that there have been a proliferation of +1's lately.
> It is also true that not too long ago community members reminded each other
> not to do that. The mantra, if I recall, was that it wasn't about
> soliciting upvotes or downvotes, but rather about posting thoughtful
> critiques, new takes on the the idea, alternative designs, etc.
>
> So I guess I'd sum up the point as this: in the current setup, everyone's
> message is treated equally (unless it exceeds the max email size limit,
> ugh); in a forum, everyone's likes are treated equally. Are we unsatisfied
> with the current community ethos? Do we want the evolution process to be
> about what ideas garnered the most votes and whose thoughts are most
> popular?
>
>
> FWIW, I think this point is moot when it comes to Discourse — the max
> allowed "likes" per day is adjustable, which I believe includes turning it
> to 0 / off. If it's determined to be harmful to "community ethos" the
> admins would be free to disable it.
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jacob Bandes-Storch via swift-evolution]

On Thu, Feb 2, 2017 at 6:37 PM, Xiaodi Wu via swift-evolution <
swift-evolution@swift.org> wrote:

> On Thu, Feb 2, 2017 at 8:03 PM, Ted kremenek via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>>
>> On Feb 2, 2017, at 5:35 PM, Karl Wagner via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> It's at least worth a beta test.
>>
>>
>> There are real concerns to work out here — just moving to the forum
>> blindly would be bad if it is highly disruptive to the community having
>> important discussions.  I DO think a forum is likely the way to go, but I
>> also am not dismissive that individuals who are highly active on
>> swift-evolution that prefer an email workflow will not have their own
>> participation significantly compromised by just moving to a forum in a
>> cavalier way.
>>
>> What I have enjoyed seeing from this thread is a healthy discussion about
>> tradeoffs of both approaches and an identification of concerns of moving
>> away from the mailing lists.  Some responses to those concerns have been
>> "Discourse can handle that", which to me is part of the evaluation of the
>> tradeoffs.  I am also really happy that Nate setup the mock Discourse setup
>> so we *could* evaluate thing like the email bridge.  For example,
>> experimenting of whether or not a rich HTML email works versus plain text
>> emails for inline responses (which turns out to have problems), etc.
>> That's all super useful for actually evaluating moving to Discourse, so in
>> my mind we are actually trying things out and identifying problem points.
>>
>> The other thing I'm considering is the practical logistics of getting
>> this set up and maintained (from an infrastructure perspective).  That's
>> not something that needs to be discussed on this thread — I'd rather the
>> thread focus on whether a forum is the right thing for the community.  But
>> it is still something that is being considered in tandem to this
>> discussion, which obviously needs to be figured out before we just jump to
>> using Discourse (if that is what we end up doing).
>>
>
> On the topic of whether a forum is the right thing for the community, I
> figure I should throw another point into the conversation. Forums are often
> designed around a rewards system to encourage participation in approved
> ways, and to encourage it frequently. People who write popular posts get
> more likes, or stars, or dingbats, and voting is encouraged from the
> community to surface the most liked/starred/dingbatted. Just earlier in
> this thread, there were explicit calls for any adopted platform to have
> liking/unliking features.
>
> In a mailing list format, everyone is free to start a new thread. 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. Yes, it's true that there have been a proliferation of +1's lately.
> It is also true that not too long ago community members reminded each other
> not to do that. The mantra, if I recall, was that it wasn't about
> soliciting upvotes or downvotes, but rather about posting thoughtful
> critiques, new takes on the the idea, alternative designs, etc.
>
> So I guess I'd sum up the point as this: in the current setup, everyone's
> message is treated equally (unless it exceeds the max email size limit,
> ugh); in a forum, everyone's likes are treated equally. Are we unsatisfied
> with the current community ethos? Do we want the evolution process to be
> about what ideas garnered the most votes and whose thoughts are most
> popular?
>

FWIW, I think this point is moot when it comes to Discourse — the max
allowed "likes" per day is adjustable, which I believe includes turning it
to 0 / off. If it's determined to be harmful to "community ethos" the
admins would be free to disable it.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

On Thu, Feb 2, 2017 at 8:03 PM, Ted kremenek via swift-evolution <
swift-evolution@swift.org> wrote:

>
>
> On Feb 2, 2017, at 5:35 PM, Karl Wagner via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> It's at least worth a beta test.
>
>
> There are real concerns to work out here — just moving to the forum
> blindly would be bad if it is highly disruptive to the community having
> important discussions.  I DO think a forum is likely the way to go, but I
> also am not dismissive that individuals who are highly active on
> swift-evolution that prefer an email workflow will not have their own
> participation significantly compromised by just moving to a forum in a
> cavalier way.
>
> What I have enjoyed seeing from this thread is a healthy discussion about
> tradeoffs of both approaches and an identification of concerns of moving
> away from the mailing lists.  Some responses to those concerns have been
> "Discourse can handle that", which to me is part of the evaluation of the
> tradeoffs.  I am also really happy that Nate setup the mock Discourse setup
> so we *could* evaluate thing like the email bridge.  For example,
> experimenting of whether or not a rich HTML email works versus plain text
> emails for inline responses (which turns out to have problems), etc.
> That's all super useful for actually evaluating moving to Discourse, so in
> my mind we are actually trying things out and identifying problem points.
>
> The other thing I'm considering is the practical logistics of getting this
> set up and maintained (from an infrastructure perspective).  That's not
> something that needs to be discussed on this thread — I'd rather the thread
> focus on whether a forum is the right thing for the community.  But it is
> still something that is being considered in tandem to this discussion,
> which obviously needs to be figured out before we just jump to using
> Discourse (if that is what we end up doing).
>

On the topic of whether a forum is the right thing for the community, I
figure I should throw another point into the conversation. Forums are often
designed around a rewards system to encourage participation in approved
ways, and to encourage it frequently. People who write popular posts get
more likes, or stars, or dingbats, and voting is encouraged from the
community to surface the most liked/starred/dingbatted. Just earlier in
this thread, there were explicit calls for any adopted platform to have
liking/unliking features.

In a mailing list format, everyone is free to start a new thread. 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. Yes, it's true that there have been a proliferation of +1's lately.
It is also true that not too long ago community members reminded each other
not to do that. The mantra, if I recall, was that it wasn't about
soliciting upvotes or downvotes, but rather about posting thoughtful
critiques, new takes on the the idea, alternative designs, etc.

So I guess I'd sum up the point as this: in the current setup, everyone's
message is treated equally (unless it exceeds the max email size limit,
ugh); in a forum, everyone's likes are treated equally. Are we unsatisfied
with the current community ethos? Do we want the evolution process to be
about what ideas garnered the most votes and whose thoughts are most
popular?
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Karl Wagner via swift-evolution]

> On 3 Feb 2017, at 02:55, Ted kremenek  wrote:
> 
> 
> 
> On Feb 2, 2017, at 12:58 PM, Karl Wagner via swift-evolution 
> > wrote:
> 
>> Personally I think that's an absurd reason not to move to a forum. What is 
>> your complaint? That it's _too_ inclusive? That others only have trivial 
>> things to say? Frankly, every way I try to interpret your comment makes it 
>> come off as snobbery.
> 
> Hi Karl,
> 
> I appreciate your candor here, but let's avoid making these comments sound 
> personal.  This is a thread prompting polarized opinions, and most of it has 
> been civil and productive.  Let's keep it that way.  I do respect that you 
> are anxious to see progress on the resolution of the topic, but these same 
> points could be made in a less antagonistic way.
> 
> I encourage all of you to re-read this part of the Code of Conduction on 
> Swift.org :
> 
>> Examples of unacceptable behavior by participants include:
>> 
>> The use of sexualized language or imagery
>> Personal attacks
>> Trolling or insulting/derogatory comments
>> Public or private harassment
>> Publishing other’s private information, such as physical or electronic 
>> addresses, without explicit permission
>> Other unethical or unprofessional conduct
>> Project maintainers have the right and responsibility to remove, edit, or 
>> reject comments, commits, code, wiki edits, issues, and other contributions 
>> that are not aligned to this Code of Conduct, or to ban temporarily or 
>> permanently any contributor for other behaviors that they deem 
>> inappropriate, threatening, offensive, or harmful.
>> 
> Thank you,
> Ted
> 

As I explained to Erica, it isn’t meant to be read personally. What I said is 
that the community should be as inclusive as possible and that prejudicing 
certain opinions as “trivial” conceptually runs against that.

That’s also my reply to the opinion others have shared that subscribing and 
publishing your email address is a kind of “good pain” to filter out the weak. 
Take the String model for example - isn’t it possible that this one particular 
discussion is critical to my business, and that I don’t really care about 
“for-else syntax” or “Annotation of Warnings/Errors” or “Compound Names for 
Enum Cases”? I don’t see the logic which says that if I care very much about 
one aspect of the language, I must care equally about everything else that ever 
changes with it.

I don’t understand why some feel it is so important to discourage ad-hoc 
contributions. Open-source lives off ad-hoc.

- Karl

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

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

[Ted kremenek via swift-evolution]

> On Feb 2, 2017, at 5:35 PM, Karl Wagner via swift-evolution 
>  wrote:
> 
> It's at least worth a beta test.

There are real concerns to work out here — just moving to the forum blindly 
would be bad if it is highly disruptive to the community having important 
discussions.  I DO think a forum is likely the way to go, but I also am not 
dismissive that individuals who are highly active on swift-evolution that 
prefer an email workflow will not have their own participation significantly 
compromised by just moving to a forum in a cavalier way.

What I have enjoyed seeing from this thread is a healthy discussion about 
tradeoffs of both approaches and an identification of concerns of moving away 
from the mailing lists.  Some responses to those concerns have been "Discourse 
can handle that", which to me is part of the evaluation of the tradeoffs.  I am 
also really happy that Nate setup the mock Discourse setup so we could evaluate 
thing like the email bridge.  For example, experimenting of whether or not a 
rich HTML email works versus plain text emails for inline responses (which 
turns out to have problems), etc.   That's all super useful for actually 
evaluating moving to Discourse, so in my mind we are actually trying things out 
and identifying problem points.

The other thing I'm considering is the practical logistics of getting this set 
up and maintained (from an infrastructure perspective).  That's not something 
that needs to be discussed on this thread — I'd rather the thread focus on 
whether a forum is the right thing for the community.  But it is still 
something that is being considered in tandem to this discussion, which 
obviously needs to be figured out before we just jump to using Discourse (if 
that is what we end up doing).

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

Re: [swift-evolution] Strings in Swift 4

[Xiaodi Wu via swift-evolution]

On Thu, Feb 2, 2017 at 9:45 AM, Dave Abrahams via swift-evolution <
swift-evolution@swift.org> wrote:

>
>
> Sent from my iPad
>
> On Feb 2, 2017, at 7:11 AM, Matthew Johnson 
> wrote:
>
>
>
> Furthermore, we emphatically do *not* need to make the distinction you
> claim between “infinite” and “incomplete” ranges, which *is* needless
> hairsplitting.
>
>
> Strongly disagree, unless you can describe the semantics of the type
> WITHOUT giving it different semantics depending on how it is used.
>
>
> This is the point that convinced me.  I’m going to take a closer look at
> Brent’s `RangeExpression` design which I must admit I only skimmed in the
> earlier discussion.
>
>
> *We already have exactly this situation* with CountableRange (which will
> merge with Range when conditional conformances land).  When used as a
> Collection, it means "every index value starting with the lowerBound and
> ending just before the upperBound".  When used for slicing, it means,
> roughly, "take every one of the collection's indices that are in bounds."
>  These are *not* the same thing.  A collection's indices* need not
> include every expressible value of the Index type between startIndex and
> endIndex*.
>

Now this is a reasonably convincing argument.

However, the conflation you describe surely comes at a price. I would bet
that if you polled ordinary Swift users, many would assume that being able
to write `myValue[startIndex.. The whole point of the name *RangeExpression* is to acknowledge this
> truth: ranges in Swift bits of syntax whose meaning is given partly by how
> they are used.
>

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.


> In fact, now that I say it, in that respect ranges are not all that
> different any other type: the meaning of a Double or an Array or a
> Bool is also interpreted by the methods to which it is passed, and can have
> completely different results depending on that context.
>

I'm not sure I understand this comment. Surely the semantic meaning of a
Double is not any more or less fluid than the semantics of the number being
modeled (for instance, 42), nor that of a Bool any more or less fluid than
the semantics of truth or falsity. But we are getting far afield here.

What I'm aiming at is that the proposed "one-sided ranges" are fuzzy on
what it is they are modeling. Now, if the community decides that this
ambiguity is a desirable thing, then so be it. I happen to think it isn't
so desirable. But in any case the decision ought to be made on the basis
that the ambiguity is worth it when exchanged for
[intuitiveness/expressiveness/whatever other advantages], not on denying
that there is ambiguity at all.

chillaxing-ly y'rs,
>
> Dave
>
> ___
> 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] [Discussion] mailing list alternative

[Ted kremenek via swift-evolution]

> On Feb 2, 2017, at 12:58 PM, Karl Wagner via swift-evolution 
>  wrote:
> 
> Personally I think that's an absurd reason not to move to a forum. What is 
> your complaint? That it's _too_ inclusive? That others only have trivial 
> things to say? Frankly, every way I try to interpret your comment makes it 
> come off as snobbery.

Hi Karl,

I appreciate your candor here, but let's avoid making these comments sound 
personal.  This is a thread prompting polarized opinions, and most of it has 
been civil and productive.  Let's keep it that way.  I do respect that you are 
anxious to see progress on the resolution of the topic, but these same points 
could be made in a less antagonistic way.

I encourage all of you to re-read this part of the Code of Conduction on 
Swift.org:

> Examples of unacceptable behavior by participants include:
> 
> The use of sexualized language or imagery
> Personal attacks
> Trolling or insulting/derogatory comments
> Public or private harassment
> Publishing other’s private information, such as physical or electronic 
> addresses, without explicit permission
> Other unethical or unprofessional conduct
> Project maintainers have the right and responsibility to remove, edit, or 
> reject comments, commits, code, wiki edits, issues, and other contributions 
> that are not aligned to this Code of Conduct, or to ban temporarily or 
> permanently any contributor for other behaviors that they deem inappropriate, 
> threatening, offensive, or harmful.
> 
Thank you,
Ted




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

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

[Karl Wagner via swift-evolution]

 
 
My complaint is really that these discussions have been good on for a year and 
we seem to get in to cyclical debates on how it *might* be, but I'd like to see 
us make a serious effort to try it.   
 
 
 

 
There are some really big discussions happening right now (e.g. the String 
model), and many more really big design discussions to be had in the near 
future (pattern matching, property behaviours, you name it...).
 

 
I think the best part of Swift is that it isn't standardised and isn't yet 
entirely fleshed-out. That means the people who use it every day have a way to 
learn about the design philosophy behind certain features, and to suggest 
meaningful and practical changes based on their experience. We're undercutting 
all of that by making it so awkward for people to get engaged.
 

 
It's at least worth a beta test.
 

 
- Karl
 
 
 

 
 
>  
> On Feb 2, 2017 at 10:45 pm,  mailto:dabrah...@apple.com)>  
> wrote:
>  
>  
>  
>  
>
> >  On Feb 2, 2017, at 12:58 PM, Karl Wagner    wrote: 
> >  
> >  somebody build a parallel site to support the style of open community 
> > which the core-team seem unwilling/unable to do. 
>
> I don't think this is fair. We may not be moving as quickly as you'd like but 
> we are looking into it. 
>
> Sent from my moss-covered three-handled family gradunza 
>  ___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Rick Mann via swift-evolution]

I thought Discourse had a mailing list gateway, such that each topic in 
Discourse would be the subject of an email, and replies to the "list" would 
append to the topic in Discourse, while subscribers to the mailing list would 
get messages for each post.

I guess that's harder with styled text, but still seems doable. I have a little 
Discourse forum I run, but have not yet figured out how to enable this 
behavior, if it even exists.

FWIW, I'd really like to have this list moved to Discourse. I think it would 
make it a lot easier to follow conversations infrequently, and shouldn't affect 
users who are immersed in it all day.

> On Feb 2, 2017, at 14:44 , Nevin Brackett-Rozinsky via swift-evolution 
>  wrote:
> 
> Where do you propose to hold and publicize such a vote in order that the 
> people who would participate on a forum but not on a mailing list—ie. those 
> for whom the switch will be most beneficial—are enfranchised?
> 
> Nevin
> 
> On Thursday, February 2, 2017, James Berry  wrote:
> 
> > On Feb 2, 2017, at 1:45 PM, Dave Abrahams via swift-evolution 
> >  wrote:
> >
> >> On Feb 2, 2017, at 12:58 PM, Karl Wagner  wrote:
> >>
> >> somebody build a parallel site to support the style of open community 
> >> which the core-team seem unwilling/unable to do.
> >
> > I don't think this is fair. We may not be moving as quickly as you'd like 
> > but we are looking into it.
> 
> I would encourage everybody to remember that though there have been a vocal 
> few advocating for something other than a mailing list, the question has 
> never really been put to the community for a vote. I think it’s important to 
> remember that while some people on list may be very vocal in advocating for a 
> position, that doesn’t mean the majority of community members agree. At the 
> least, such a matter should be put to a vote or poll once leading options 
> have been identified.
> 
> Speaking for myself only, discourse seems to give me little of value, while 
> it would plaster emails with html-laden buttons, etc, thus making my favored 
> experience worse than it is today. I’m fairly happy with using a gmail 
> account and server-side filters to file my swift-evolution mails into a 
> mailbox that I can then read on or offline with the threaded email client of 
> my choice.
> 
> James
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution


-- 
Rick Mann
rm...@latencyzero.com


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

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

[Dimitri Racordon via swift-evolution]

Is there any reason we should keep holding back from giving Discourse a 
**real** try?

Most arguments I read were pointed at filtering/flagging issues, or at how the 
focus of the discussions could change. I’ve only tried Discourse once, but to 
the best of my knowledge, it totally addresses the first issue. As for how the 
discussions would change, while I personally seriously doubt it, no one can 
definitively say it will or won’t go this path unless we try. I also read some 
concerns about email addresses being released in the wild, but maybe we could 
use some alias until something more official is set up.

Apparently I’m not the only one who thinks the benefits largely outweigh the 
drawbacks, so at least let’s give it a real try. Besides, I think we could (or 
even **should**) go forward with that test before we think about voting and/or 
how to vote. It could very well confirm/invalidate most of the “imho” arguments.

Aren’t we all somehow familiar with the benefits of testing? =D

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

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

[James Berry via swift-evolution]

> On Feb 2, 2017, at 2:44 PM, Nevin Brackett-Rozinsky via swift-evolution 
>  wrote:
> 
> Where do you propose to hold and publicize such a vote in order that the 
> people who would participate on a forum but not on a mailing list—ie. those 
> for whom the switch will be most beneficial—are enfranchised?

The traditional method on a list like this is +1 or -1 in response to a given 
thread. (Note that I’m not calling for such a vote, as I have nothing to 
propose). A perhaps more modern approach would be to give a link to an external 
site that would run the vote/poll.

As to your question of how to reach an audience larger than what we have now 
for a vote, I don’t see any obvious solution: the current community is what it 
is. And I would argue that the current community has invested the most time 
into the project (and likely will going forward) and should have the largest 
vote for how project communication should be facilitated. I wouldn’t advocate 
for advertising far and wide over the internet “how should the swift-evolution 
community communicate?”, as this would be a vote of the internet, and not of 
the swift-evolution community. I do admit you could argue the community may 
have already self-selected to some degree based on the current method of 
commutation; I see no real solution to that apart from continued advocacy from 
people such as you who are speaking up to bring awareness about the issues you 
feel are keeping outsiders from participating.

James


> 
> Nevin
> 
> On Thursday, February 2, 2017, James Berry  > wrote:
> 
> > On Feb 2, 2017, at 1:45 PM, Dave Abrahams via swift-evolution 
> > > wrote:
> >
> >> On Feb 2, 2017, at 12:58 PM, Karl Wagner  >> > wrote:
> >>
> >> somebody build a parallel site to support the style of open community 
> >> which the core-team seem unwilling/unable to do.
> >
> > I don't think this is fair. We may not be moving as quickly as you'd like 
> > but we are looking into it.
> 
> I would encourage everybody to remember that though there have been a vocal 
> few advocating for something other than a mailing list, the question has 
> never really been put to the community for a vote. I think it’s important to 
> remember that while some people on list may be very vocal in advocating for a 
> position, that doesn’t mean the majority of community members agree. At the 
> least, such a matter should be put to a vote or poll once leading options 
> have been identified.
> 
> Speaking for myself only, discourse seems to give me little of value, while 
> it would plaster emails with html-laden buttons, etc, thus making my favored 
> experience worse than it is today. I’m fairly happy with using a gmail 
> account and server-side filters to file my swift-evolution mails into a 
> mailbox that I can then read on or offline with the threaded email client of 
> my choice.
> 
> James
> 
> ___
> 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] Subclass Existentials

[Douglas Gregor via swift-evolution]

> 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.

- Doug


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

Re: [swift-evolution] Subclass Existentials

[David Smith via swift-evolution]

> 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.

David

> 
>   - Doug
> 
> 
>> 
>> 
>> -- 
>> Adrian Zubarev
>> Sent with Airmail
>> 
>> Am 2. Februar 2017 um 05:52:41, Douglas Gregor via swift-evolution 
>> (swift-evolution@swift.org ) schrieb:
>> 
>>> 
>>> 
>>> Sent from my iPhone
>>> 
>>> On Feb 1, 2017, at 8:46 PM, Slava Pestov >> > wrote:
>>> 
 
> On Feb 1, 2017, at 4:09 PM, Douglas Gregor via swift-evolution 
> > wrote:
> 
>> 
>> On Feb 1, 2017, at 3:13 PM, David Hart > > wrote:
>> 
>> Second question inline:
>> 
>> 
>> 
>> Sent from my iPhone
>> On 1 Feb 2017, at 23:09, David Hart > > wrote:
>> 
>>> I did consider it, but didn’t want to put too much on your plate for 
>>> Swift 4. But if you’re mentioning it, I’ll go ahead and add it to the 
>>> second version of the proposal.
>>> 
>>> By the way, what you is your point of view about the discussions we’ve 
>>> had concerning the positioning of the class constraint?
>>> 
>>> David.
>>> 
 On 1 Feb 2017, at 22:58, Douglas Gregor > wrote:
 
 
> On Jan 29, 2017, at 8:39 AM, David Hart  > wrote:
> 
> Hello,
> 
> As promised, I wrote the first draft of a proposal to add class 
> requirements to 

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

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

I can only say how I perceive the mailing list from my own perspective:

The mailing list is a really confusing way of following the discussions for me. 
I never know the context of an answer since my mail clients don’t show the 
quoted parts correctly. Also I get a lot of emails throughout the day on all my 
devices (including my Apple Watch), even when I’m really not into reading them. 
I’d have to create an extra email account or setup some magic filtering to fix 
this, also make sure I get push notifications only for those other accounts 
etc. – but this is all too much overhead. Therefore the only options for me 
are: Get all emails or get none. Everything else it too complicated to 
configure, given that I just want to read some threads that sound interesting 
to me and maybe post some ideas here and there.

Discourse is a tool that I like very much and find very clean and 
understandable. Also it has a thread-summarize feature which would help a lot 
to get an overview of longer-discussed threads for those of us coming in later 
on. Note that I once followed the mailing list at the relative beginning of the 
open source Swift project and stopped doing that simply because it was too many 
emails that came into my mailbox that I didn’t care about. And that’s what I’m 
experiencing now again given that I opted in since a week or so now.

What I actually wanted or expected Swift Evolution for me to be was a go-to 
solution which I can open when I have time and read about discussion on one 
side and help out with ideas or vote on some issues on the other. I’ve tried 
Hirundo, I have even tried a folder which contains all Swift threads, I tried 
Apple Mail and Airmail 3 – but none of them was simple or useful enough, I 
could never find what I was looking for. Maybe I’m just too stupid for this 
mailing list, but one thing I know for sure: Discourse would have definitely 
solved this problem for me. I wondered from the beginning, why a big company 
like Apple would ever even consider choosing such a poor and unclean interface 
like a mailing list for discussions. I thought I’m missing something and it’s a 
lot more productive and tried to use it – but it simply doesn’t fit my needs.

I can understand how a mailing list is interesting if you are working on 
developing Swift all-day and don’t want to miss any message. But for the open 
source from-time-to-time contributors and followers of the Swift evolution 
discussions I don’t think email is a good solution. Discourse would be great 
for these cases. So, for me personally, if Discourse (or a similar alternative) 
isn’t considered and tried to be introduced, it means that the goal of Swift is 
not to have a broad contributing community but rather a small group of people 
who invest a lot of time to improve the Swift language. Earlier I didn’t think 
like that, I didn’t think about it at all, I just accepted the mailing list 
with „it is, what it is“. But now that I know others feel the same or similarly 
and therefore the guys at Apple are aware of the problem, I’m feeling like 
this, like that this is a question of how broad the community should be. I’d 
like to be a part of it, but the mailing list is not my thing. I’d probably 
drop out soon again … so this is what I think. It might not be of any value for 
the community, but maybe it’s a voice that wants to be heard, so I’m letting 
you hear it.

-- 
Cihat Gündüz

Am 2. Februar 2017 um 22:47:11, Dave Abrahams via swift-evolution 
(swift-evolution@swift.org) schrieb:



> On Feb 2, 2017, at 12:58 PM, Karl Wagner  wrote:
>  
> somebody build a parallel site to support the style of open community which 
> the core-team seem unwilling/unable to do.

I don't think this is fair. We may not be moving as quickly as you'd like but 
we are looking into it.  

Sent from my moss-covered three-handled family gradunza
___
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] [Discussion] mailing list alternative

[Nevin Brackett-Rozinsky via swift-evolution]

Where do you propose to hold and publicize such a vote in order that
the people who would participate on a forum but not on a mailing
list—ie. those for whom the switch will be most beneficial—are enfranchised?

Nevin

On Thursday, February 2, 2017, James Berry  wrote:

>
> > On Feb 2, 2017, at 1:45 PM, Dave Abrahams via swift-evolution <
> swift-evolution@swift.org > wrote:
> >
> >> On Feb 2, 2017, at 12:58 PM, Karl Wagner  > wrote:
> >>
> >> somebody build a parallel site to support the style of open community
> which the core-team seem unwilling/unable to do.
> >
> > I don't think this is fair. We may not be moving as quickly as you'd
> like but we are looking into it.
>
> I would encourage everybody to remember that though there have been a
> vocal few advocating for something other than a mailing list, the question
> has never really been put to the community for a vote. I think it’s
> important to remember that while some people on list may be very vocal in
> advocating for a position, that doesn’t mean the majority of community
> members agree. At the least, such a matter should be put to a vote or poll
> once leading options have been identified.
>
> Speaking for myself only, discourse seems to give me little of value,
> while it would plaster emails with html-laden buttons, etc, thus making my
> favored experience worse than it is today. I’m fairly happy with using a
> gmail account and server-side filters to file my swift-evolution mails into
> a mailbox that I can then read on or offline with the threaded email client
> of my choice.
>
> James
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[James Berry via swift-evolution]

> On Feb 2, 2017, at 1:45 PM, Dave Abrahams via swift-evolution 
>  wrote:
> 
>> On Feb 2, 2017, at 12:58 PM, Karl Wagner  wrote:
>> 
>> somebody build a parallel site to support the style of open community which 
>> the core-team seem unwilling/unable to do.
> 
> I don't think this is fair. We may not be moving as quickly as you'd like but 
> we are looking into it. 

I would encourage everybody to remember that though there have been a vocal few 
advocating for something other than a mailing list, the question has never 
really been put to the community for a vote. I think it’s important to remember 
that while some people on list may be very vocal in advocating for a position, 
that doesn’t mean the majority of community members agree. At the least, such a 
matter should be put to a vote or poll once leading options have been 
identified.

Speaking for myself only, discourse seems to give me little of value, while it 
would plaster emails with html-laden buttons, etc, thus making my favored 
experience worse than it is today. I’m fairly happy with using a gmail account 
and server-side filters to file my swift-evolution mails into a mailbox that I 
can then read on or offline with the threaded email client of my choice.

James

___
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, Jonathan Hull  wrote:

> Just out of curiosity, what are the use-cases for an infinite sequence
> (as opposed to a sequence which is bounded to the type’s representable
> values)?

1. The type may not have an inherent expressible bound (see BigInt,
   UnsafePointer, and *many* real-life Index types).

2. I keep repeating variants of this example:

  func listElements<
S: Sequence, N: Number
  >(of s: S, numberedFrom start: N) {
for (n, e) in zip(start..., s) {
  print("\(n). \(e)")
}
  }

  which avoids incorrect behavior when N turns out to be a type that
  can't represent values high enough to list everything in s—**if and
  only if** `start...` is an unbounded range, rather than one that
  implicitly gets its upper bound from its type.

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

Re: [swift-evolution] Either protocol syntax

[Matthew Johnson via swift-evolution]

> On Feb 2, 2017, at 4:02 PM, Rex Fenley  wrote:
> 
> But then any time as user of the pipeline I'm writing would like a new type 
> of collection they will be forced to inherit this new protocol vs one they're 
> already familiar with and which the collection may already conform too.

Yes, that is true.  But if you design your new protocol such that it’s 
requirements all match a requirement in `RangeReplaceableCollection` then 
conformance will be a one-line extension.  This may not be ideal, but it’s 
really not too bad and you can do it today.

> 
> On Thu, Feb 2, 2017 at 1:53 PM, Matthew Johnson  > wrote:
> 
>> On Feb 2, 2017, at 3:46 PM, Rex Fenley > > wrote:
>> 
>> My use case is RLMArray and it can't implement RangeReplaceableCollection 
>> though because `init` is unavailable, additionally, there's a lot of parts 
>> to the protocol that would take some time to implement correctly if I could. 
>> They offer a Swift type List that wraps RLMArray and does a bunch of stuff 
>> to implement RangeReplaceableCollection, but they discourage using their 
>> Swift library in mixed Obj-C/Swift projects and certain model objects simply 
>> couldn't use the List type anyway because they're also used in Obj-C and 
>> List is not @objc compliant.
>> 
>> So this leaves me in situations where when I need to use Array or RLMArray I 
>> have to duplicate my code, not just in one place, but all the way down a 
>> pipeline in order to have my generics work with either 
>> RangeReplaceableCollection or RLMArray.
>> 
>> If I could abstract the commonalities required by my application, I could 
>> just have a RLMArrayProtocol that has RLMArray's exposed function signatures 
>> and a new protocol Appendable = RangeReplaceableCollection | 
>> RLMArrayProtocol and this will type check all the way through the pipeline.
>> 
>> tl;dr - if a function signature required by a protocol is marked unavailable 
>> on a class, then disjunction is necessary in order to bridge the two (or 
>> more) types without duplicating code.
> 
> You should be able to solve this problem today by creating a custom protocol 
> that you use as a constraint in your generic code and providing conformances 
> for both Array and RLMArray.
> 
>> 
>> On Thu, Feb 2, 2017 at 1:35 PM, Matthew Johnson > > wrote:
>>> 
>>> On Feb 2, 2017, at 3:26 PM, Rex Fenley via swift-evolution 
>>> > wrote:
>>> 
>>> Hello, I believe there was some discussion about this quite awhile ago. I 
>>> was wondering if there's any interest in including a protocol 'or' type 
>>> that would be the intersection of two protocols. This could be really 
>>> useful in situations where a framework that the user has no control over 
>>> implements a portion of some often used protocol. Such as specialized 
>>> collections from an Database framework that don't implement 
>>> RangeReplaceableCollection but have a set of methods that are equivalent. 
>>> The user can then implement a protocol that is the intersection of those 
>>> set of methods and not duplicate code.
>> 
>> If the specialized collection in the database framework already provides 
>> functionality equivalent to `RangeReplaceableCollection` what you really 
>> want to do is just provide the conformance you’re looking for in an 
>> extension:
>> 
>> extension SpecializedDatabaseCollection: RangeReplaceableCollection {
>>// if necessary, provide forwarding wrappers where the member names don’t 
>> match up.
>> }
>> 
>> But in a case like this the framework itself really should provide this 
>> conformance out of the box.  If they didn’t, maybe there is a good reason so 
>> you would want to find out why it wasn’t provided.
>> 
>> Is there something you’re hoping to do that you can’t solve by simply 
>> extending the framework types?
>> 
>>> 
>>> Simplified example:
>>> 
>>> protocol Animal {
>>> var hasEars: Bool { get }
>>> func grow()
>>> }
>>> 
>>> protocol Plant {
>>> var isGreen: Bool { get }
>>> func grow()
>>> }
>>> 
>>> protocol LivingThing = Plant | Animal // or a different syntax
>>> 
>>> LivingThing's is as follows
>>> {
>>> func grow()
>>> }
>>> 
>>> -- 
>>> Rex Fenley  |  IOS DEVELOPER
>>> 
>>> 
>>> Remind.com  |  BLOG   |  
>>> FOLLOW US   |  LIKE US 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 
>> 
>> 
>> 
>> 
>> -- 
>> Rex Fenley  |  IOS DEVELOPER
>> 
>> 
>> Remind.com  |  BLOG 

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

[David Sweeris via swift-evolution]

> On Feb 2, 2017, at 09:52, Freak Show via swift-evolution 
>  wrote:
> 
> Yeah, that's what I want - more "annotations" cluttering up my Objective C 
> headers to make Swift happy.
> 
> No thanks.  There's enough noise introduced already.

It'd be cluttering up Apple's code, not yours (unless you work for them, of 
course).

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

Re: [swift-evolution] Either protocol syntax

[Robert Widmann via swift-evolution]

It sounds like what you want is an GADT-like adaptor gadget to try to bridge 
between these protocols across these specific types.  With general disjuncts 
you’re subject to the open world assumption - that anybody that should conform 
to a (visible) protocol, can conform to that protocol - thus rendering any 
attempts to inspect the kind of thing you’ve got in the disjunct useless.

~Robert Widmann


> On Feb 2, 2017, at 5:02 PM, Rex Fenley via swift-evolution 
>  wrote:
> 
> But then any time as user of the pipeline I'm writing would like a new type 
> of collection they will be forced to inherit this new protocol vs one they're 
> already familiar with and which the collection may already conform too.
> 
> On Thu, Feb 2, 2017 at 1:53 PM, Matthew Johnson  > wrote:
> 
>> On Feb 2, 2017, at 3:46 PM, Rex Fenley > > wrote:
>> 
>> My use case is RLMArray and it can't implement RangeReplaceableCollection 
>> though because `init` is unavailable, additionally, there's a lot of parts 
>> to the protocol that would take some time to implement correctly if I could. 
>> They offer a Swift type List that wraps RLMArray and does a bunch of stuff 
>> to implement RangeReplaceableCollection, but they discourage using their 
>> Swift library in mixed Obj-C/Swift projects and certain model objects simply 
>> couldn't use the List type anyway because they're also used in Obj-C and 
>> List is not @objc compliant.
>> 
>> So this leaves me in situations where when I need to use Array or RLMArray I 
>> have to duplicate my code, not just in one place, but all the way down a 
>> pipeline in order to have my generics work with either 
>> RangeReplaceableCollection or RLMArray.
>> 
>> If I could abstract the commonalities required by my application, I could 
>> just have a RLMArrayProtocol that has RLMArray's exposed function signatures 
>> and a new protocol Appendable = RangeReplaceableCollection | 
>> RLMArrayProtocol and this will type check all the way through the pipeline.
>> 
>> tl;dr - if a function signature required by a protocol is marked unavailable 
>> on a class, then disjunction is necessary in order to bridge the two (or 
>> more) types without duplicating code.
> 
> You should be able to solve this problem today by creating a custom protocol 
> that you use as a constraint in your generic code and providing conformances 
> for both Array and RLMArray.
> 
>> 
>> On Thu, Feb 2, 2017 at 1:35 PM, Matthew Johnson > >wrote:
>>> 
>>> On Feb 2, 2017, at 3:26 PM, Rex Fenley via swift-evolution 
>>> > wrote:
>>> 
>>> Hello, I believe there was some discussion about this quite awhile ago. I 
>>> was wondering if there's any interest in including a protocol 'or' type 
>>> that would be the intersection of two protocols. This could be really 
>>> useful in situations where a framework that the user has no control over 
>>> implements a portion of some often used protocol. Such as specialized 
>>> collections from an Database framework that don't implement 
>>> RangeReplaceableCollection but have a set of methods that are equivalent. 
>>> The user can then implement a protocol that is the intersection of those 
>>> set of methods and not duplicate code.
>> 
>> If the specialized collection in the database framework already provides 
>> functionality equivalent to `RangeReplaceableCollection` what you really 
>> want to do is just provide the conformance you’re looking for in an 
>> extension:
>> 
>> extension SpecializedDatabaseCollection: RangeReplaceableCollection {
>>// if necessary, provide forwarding wrappers where the member names don’t 
>> match up.
>> }
>> 
>> But in a case like this the framework itself really should provide this 
>> conformance out of the box.  If they didn’t, maybe there is a good reason so 
>> you would want to find out why it wasn’t provided.
>> 
>> Is there something you’re hoping to do that you can’t solve by simply 
>> extending the framework types?
>> 
>>> 
>>> Simplified example:
>>> 
>>> protocol Animal {
>>> var hasEars: Bool { get }
>>> func grow()
>>> }
>>> 
>>> protocol Plant {
>>> var isGreen: Bool { get }
>>> func grow()
>>> }
>>> 
>>> protocol LivingThing = Plant | Animal // or a different syntax
>>> 
>>> LivingThing's is as follows
>>> {
>>> func grow()
>>> }
>>> 
>>> -- 
>>> Rex Fenley  |  IOS DEVELOPER
>>> 
>>> 
>>> Remind.com  |  BLOG   |  
>>> FOLLOW US   |  LIKE US 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 

Re: [swift-evolution] Either protocol syntax

[Rex Fenley via swift-evolution]

But then any time as user of the pipeline I'm writing would like a new type
of collection they will be forced to inherit this new protocol vs one
they're already familiar with and which the collection may already conform
too.

On Thu, Feb 2, 2017 at 1:53 PM, Matthew Johnson 
wrote:

>
> On Feb 2, 2017, at 3:46 PM, Rex Fenley  wrote:
>
> My use case is RLMArray and it can't implement RangeReplaceableCollection 
> though
> because `init` is unavailable, additionally, there's a lot of parts to the
> protocol that would take some time to implement correctly if I could. They
> offer a Swift type List that wraps RLMArray and does a bunch of stuff to
> implement RangeReplaceableCollection, but they discourage using their
> Swift library in mixed Obj-C/Swift projects and certain model objects
> simply couldn't use the List type anyway because they're also used in Obj-C
> and List is not @objc compliant.
>
> So this leaves me in situations where when I need to use Array or RLMArray
> I have to duplicate my code, not just in one place, but all the way down a
> pipeline in order to have my generics work with either
> RangeReplaceableCollection or RLMArray.
>
> If I could abstract the commonalities required by my application, I could
> just have a RLMArrayProtocol that has RLMArray's exposed function
> signatures and a new protocol Appendable = RangeReplaceableCollection | 
> RLMArrayProtocol
> and this will type check all the way through the pipeline.
>
> tl;dr - if a function signature required by a protocol is marked
> unavailable on a class, then disjunction is necessary in order to bridge
> the two (or more) types without duplicating code.
>
>
> You should be able to solve this problem today by creating a custom
> protocol that you use as a constraint in your generic code and providing
> conformances for both Array and RLMArray.
>
>
> On Thu, Feb 2, 2017 at 1:35 PM, Matthew Johnson 
> wrote:
>
>>
>> On Feb 2, 2017, at 3:26 PM, Rex Fenley via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> Hello, I believe there was some discussion about this quite awhile ago. I
>> was wondering if there's any interest in including a protocol 'or' type
>> that would be the intersection of two protocols. This could be really
>> useful in situations where a framework that the user has no control over
>> implements a portion of some often used protocol. Such as specialized
>> collections from an Database framework that don't implement
>> RangeReplaceableCollection but have a set of methods that are equivalent.
>> The user can then implement a protocol that is the intersection of those
>> set of methods and not duplicate code.
>>
>>
>> If the specialized collection in the database framework already provides
>> functionality equivalent to `RangeReplaceableCollection` what you really
>> want to do is just provide the conformance you’re looking for in an
>> extension:
>>
>> extension SpecializedDatabaseCollection: RangeReplaceableCollection {
>>// if necessary, provide forwarding wrappers where the member names
>> don’t match up.
>> }
>>
>> But in a case like this the framework itself really should provide this
>> conformance out of the box.  If they didn’t, maybe there is a good reason
>> so you would want to find out why it wasn’t provided.
>>
>> Is there something you’re hoping to do that you can’t solve by simply
>> extending the framework types?
>>
>>
>> Simplified example:
>>
>> protocol Animal {
>> var hasEars: Bool { get }
>> func grow()
>> }
>>
>> protocol Plant {
>> var isGreen: Bool { get }
>> func grow()
>> }
>>
>> protocol LivingThing = Plant | Animal // or a different syntax
>>
>> LivingThing's is as follows
>> {
>> func grow()
>> }
>>
>>
>> --
>> Rex Fenley  |  IOS DEVELOPER
>>
>> Remind.com  |  BLOG 
>>  |  FOLLOW US   |  LIKE US
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>>
>
>
> --
> Rex Fenley  |  IOS DEVELOPER
>
> Remind.com  |  BLOG   |
>  FOLLOW US   |  LIKE US
> 
>
>
>


-- 

Rex Fenley  |  IOS DEVELOPER

Remind.com  |  BLOG 
 |  FOLLOW
US   |  LIKE US

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

Re: [swift-evolution] Either protocol syntax

[Rex Fenley via swift-evolution]

My use case is RLMArray and it can't implement
RangeReplaceableCollection though
because `init` is unavailable, additionally, there's a lot of parts to the
protocol that would take some time to implement correctly if I could. They
offer a Swift type List that wraps RLMArray and does a bunch of stuff to
implement RangeReplaceableCollection, but they discourage using their Swift
library in mixed Obj-C/Swift projects and certain model objects simply
couldn't use the List type anyway because they're also used in Obj-C and
List is not @objc compliant.

So this leaves me in situations where when I need to use Array or RLMArray
I have to duplicate my code, not just in one place, but all the way down a
pipeline in order to have my generics work with either
RangeReplaceableCollection
or RLMArray.

If I could abstract the commonalities required by my application, I could
just have a RLMArrayProtocol that has RLMArray's exposed function
signatures and a new protocol Appendable = RangeReplaceableCollection
| RLMArrayProtocol
and this will type check all the way through the pipeline.

tl;dr - if a function signature required by a protocol is marked
unavailable on a class, then disjunction is necessary in order to bridge
the two (or more) types without duplicating code.

On Thu, Feb 2, 2017 at 1:35 PM, Matthew Johnson 
wrote:

>
> On Feb 2, 2017, at 3:26 PM, Rex Fenley via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Hello, I believe there was some discussion about this quite awhile ago. I
> was wondering if there's any interest in including a protocol 'or' type
> that would be the intersection of two protocols. This could be really
> useful in situations where a framework that the user has no control over
> implements a portion of some often used protocol. Such as specialized
> collections from an Database framework that don't implement
> RangeReplaceableCollection but have a set of methods that are equivalent.
> The user can then implement a protocol that is the intersection of those
> set of methods and not duplicate code.
>
>
> If the specialized collection in the database framework already provides
> functionality equivalent to `RangeReplaceableCollection` what you really
> want to do is just provide the conformance you’re looking for in an
> extension:
>
> extension SpecializedDatabaseCollection: RangeReplaceableCollection {
>// if necessary, provide forwarding wrappers where the member names
> don’t match up.
> }
>
> But in a case like this the framework itself really should provide this
> conformance out of the box.  If they didn’t, maybe there is a good reason
> so you would want to find out why it wasn’t provided.
>
> Is there something you’re hoping to do that you can’t solve by simply
> extending the framework types?
>
>
> Simplified example:
>
> protocol Animal {
> var hasEars: Bool { get }
> func grow()
> }
>
> protocol Plant {
> var isGreen: Bool { get }
> func grow()
> }
>
> protocol LivingThing = Plant | Animal // or a different syntax
>
> LivingThing's is as follows
> {
> func grow()
> }
>
>
> --
> Rex Fenley  |  IOS DEVELOPER
>
> Remind.com  |  BLOG   |
>  FOLLOW US   |  LIKE US
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>


-- 

Rex Fenley  |  IOS DEVELOPER

Remind.com  |  BLOG 
 |  FOLLOW
US   |  LIKE US

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

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

[Dave Abrahams via swift-evolution]

> On Feb 2, 2017, at 12:58 PM, Karl Wagner  wrote:
> 
> somebody build a parallel site to support the style of open community which 
> the core-team seem unwilling/unable to do.

I don't think this is fair. We may not be moving as quickly as you'd like but 
we are looking into it. 

Sent from my moss-covered three-handled family gradunza
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Either protocol syntax

[Adrian Zubarev via swift-evolution]

Look for Disjunctions (logical ORs) in type constraints. ;)

It’s rejected.



-- 
Adrian Zubarev
Sent with Airmail

Am 2. Februar 2017 um 22:26:44, Rex Fenley via swift-evolution 
(swift-evolution@swift.org) schrieb:

Hello, I believe there was some discussion about this quite awhile ago. I was 
wondering if there's any interest in including a protocol 'or' type that would 
be the intersection of two protocols. This could be really useful in situations 
where a framework that the user has no control over implements a portion of 
some often used protocol. Such as specialized collections from an Database 
framework that don't implement RangeReplaceableCollection but have a set of 
methods that are equivalent. The user can then implement a protocol that is the 
intersection of those set of methods and not duplicate code.

Simplified example:

protocol Animal {
    var hasEars: Bool { get }
    func grow()
}

protocol Plant {
    var isGreen: Bool { get }
    func grow()
}

protocol LivingThing = Plant | Animal // or a different syntax

LivingThing's is as follows
{
    func grow()
}

--

Rex Fenley  
 |  
 IOS
DEVELOPER

  


Remind.com  
|  BLOG  
 |  FOLLOW
US  
 |  
 LIKE US
___
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] Either protocol syntax

[Matthew Johnson via swift-evolution]

> 
> On Feb 2, 2017, at 3:26 PM, Rex Fenley via swift-evolution 
>  wrote:
> 
> Hello, I believe there was some discussion about this quite awhile ago. I was 
> wondering if there's any interest in including a protocol 'or' type that 
> would be the intersection of two protocols. This could be really useful in 
> situations where a framework that the user has no control over implements a 
> portion of some often used protocol. Such as specialized collections from an 
> Database framework that don't implement RangeReplaceableCollection but have a 
> set of methods that are equivalent. The user can then implement a protocol 
> that is the intersection of those set of methods and not duplicate code.

If the specialized collection in the database framework already provides 
functionality equivalent to `RangeReplaceableCollection` what you really want 
to do is just provide the conformance you’re looking for in an extension:

extension SpecializedDatabaseCollection: RangeReplaceableCollection {
   // if necessary, provide forwarding wrappers where the member names don’t 
match up.
}

But in a case like this the framework itself really should provide this 
conformance out of the box.  If they didn’t, maybe there is a good reason so 
you would want to find out why it wasn’t provided.

Is there something you’re hoping to do that you can’t solve by simply extending 
the framework types?

> 
> Simplified example:
> 
> protocol Animal {
> var hasEars: Bool { get }
> func grow()
> }
> 
> protocol Plant {
> var isGreen: Bool { get }
> func grow()
> }
> 
> protocol LivingThing = Plant | Animal // or a different syntax
> 
> LivingThing's is as follows
> {
> func grow()
> }
> 
> -- 
> Rex Fenley  |  IOS DEVELOPER
> 
> 
> Remind.com  |  BLOG   |  
> FOLLOW US   |  LIKE US 
> ___
> 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] Either protocol syntax

[Rex Fenley via swift-evolution]

Hello, I believe there was some discussion about this quite awhile ago. I
was wondering if there's any interest in including a protocol 'or' type
that would be the intersection of two protocols. This could be really
useful in situations where a framework that the user has no control over
implements a portion of some often used protocol. Such as specialized
collections from an Database framework that don't implement
RangeReplaceableCollection but have a set of methods that are equivalent.
The user can then implement a protocol that is the intersection of those
set of methods and not duplicate code.

Simplified example:

protocol Animal {
var hasEars: Bool { get }
func grow()
}

protocol Plant {
var isGreen: Bool { get }
func grow()
}

protocol LivingThing = Plant | Animal // or a different syntax

LivingThing's is as follows
{
func grow()
}

-- 

Rex Fenley  |  IOS DEVELOPER

Remind.com  |  BLOG 
 |  FOLLOW
US   |  LIKE US

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

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

[Karl Wagner via swift-evolution]

 
 
It discourages trivial contributions in theory only. In practice there is no 
difference. I see plenty of one-line comments and corrections. Take a look at 
any reasonably long thread on here and I'm sure you'll see the same.
 

 
Personally I think that's an absurd reason not to move to a forum. What is your 
complaint? That it's _too_ inclusive? That others only have trivial things to 
say? Frankly, every way I try to interpret your comment makes it come off as 
snobbery.
 

 
This change is long overdue, and I'd recommend we either start beta-testing on 
swift.org or somebody build a parallel site to support the style of open 
community which the core-team seem unwilling/unable to do.
 

 
These threads come up pretty much every month. We have a proof of concept. Just 
like any change, there will be some esoteric cases where people are less happy, 
but it's frankly absurd to suggest this wouldn't be a hugely popular change. Do 
a formal proposal if you want -- I would lay money on it getting passed.
 

 
- Karl
 
 
 

 
>  
> On Feb 2, 2017 at 7:45 pm,   (mailto:swift-evolution@swift.org)>  wrote:
>  
>  
>  
>  
>  
> >  
> > On Feb 1, 2017, at 4:34 AM, David Hart via swift-evolution  
> >   wrote:
> >  
> >  
> >  
> >
> >  
> >  On 1 Feb 2017, at 06:59, Thorsten Seitz via swift-evolution  
> >   wrote:
> >  
> >  
> > >  
> > >  
> > >
> > >  
> > > While I'm not really happy with the mailing list, this is mostly due to 
> > > restrictions of iOS Mail which makes keeping track of relevant threads 
> > > and filtering out threads I'm not interested in difficult.
> > >  
> > >
> > >  
> > > The mailing list has one important advantage over a web interface: most 
> > > of my reading happens on a train to and from work. On this train the 
> > > connection is for most parts of the ride so bad that I can't download new 
> > > messages, but fortunately that is not necessary because I can read all 
> > > those messages I downloaded earlier on the railway station.
> > >  
> > > With a web interface I expect that to be much more problematic because it 
> > > would have to download each message or maybe at least each thread on 
> > > demand.
> > >  
> > >  
> >  
> >
> >  
> > Discourse has a mailing list mode to have send you and accept email 
> > replies. You'd be covered.
> >  
> >
>  
> Discourse has the outward appearance of a forum. Because of that, it will 
> naturally adopt the social behaviors typical of a forum. In forums, light 
> back and forth is common, and there's no way for mods to "remove" messages 
> from having been emailed out. Natural forum-like idle chatter can overwhelm 
> the traffic of those of us who prefer mailing list mode so we can sort, 
> track, flag, and filter the on-list conversations.To get a sense, check 
> out the traffic on  https://swift-lang.slack.com  and  
> https://iosdevelopers.slack.com.
>  
>
>  
> A mailing list discourages off-topic and trivial contributions.I could 
> easily see being sent dozens of emails from a single back and forth.
> Increased traffic would force most users to migrate from email to direct 
> Discourse forums and direct forum use loses the ability to flag, filter, and 
> sort discussions. You can't scan, mark, and put away threads you've already 
> dealt with. This would be a massive loss of utility for those of us who need 
> to keep on top of language discussions for work.
>  
>
>  
> I do prefer upgrading to Mailman 3.
>  
>
>  
> -- E
>  
>
>  ___ swift-evolution mailing list 
>  swift-evolution@swift.org (mailto:swift-evolution@swift.org)   
> https://lists.swift.org/mailman/listinfo/swift-evolution  ___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Zach Drayer via swift-evolution]

Anything that encourages people to participate is a good thing in my book. 
Mailing lists are nice, but also not a thing many people are comfortable with.

A system that better supports threads means there is less of a cost to people 
having a back-and-forth than there is today, which also seems to be hugely 
beneficial (whether it be letting people hammer out ideas without disturbing 
everyone, or asking a question about something without pulling attention away 
from the main topic at hand).

I understand that there’s only so much bandwidth to go around, that the team 
may like to focus energies elsewhere (and maybe that technical problems are 
easier to solve than social ones), but use of a mailing list has been a topic 
that the community has been bringing up since the very beginning (the earliest 
thread I can find is from a few days after the list was announced: titled 
“Mailman?”, and from Dec 10, 2015; 
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001537.html
 
).
 Since then, we’ve had a number of Swift proposals, manifestos, and releases 
(not the least of which is Swift 3, which was a tremendous amount of amazing 
work).

Managing communities is definitely hard work, and I really do appreciate how 
much energy everyone already puts into this  —  especially when it’s not 
necessarily a core part of anyone's job. That said, it really would be great if 
some attention could be given to how the community itself works, to come up 
with new ways to let people be involved and to double check that the processes 
we’ve been using are good to go for the next year (for example: I’m still not 
sure of the correct way to revisit an enhancement is after it’s acceptance and 
implementation, and some enhancements like `fileprivate` warrant revisiting).

Thanks,
-z___
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]

> A mailing list discourages off-topic and trivial contributions.  I could 
> easily see being sent dozens of emails from a single back and forth.  
> Increased traffic would force most users to migrate from email to direct 
> Discourse forums and direct forum use loses the ability to flag, filter, and 
> sort discussions. You can't scan, mark, and put away threads you've already 
> dealt with. This would be a massive loss of utility for those of us who need 
> to keep on top of language discussions for work.


True, the mailing list discourages trivial contributions: I never wrote a 
message whose only new content was "+1", and rarely see those in my inbox…
This has a positive aspect, because it keeps the number of mails lower, but it 
also has very bad effects.
It's a very realistic scenario that someone expresses a really clever thought 
that is endorsed by everyone, yet receiving no feedback because no one has to 
add something to it (and doesn't want to write a regular message without real 
content).
This is daunting for the author who feels ignored despite (invisible) 
agreement, thus discouraging to continue contributing.

A forum, on the other hand, is much more flexible and allows lightweight 
reactions without polluting the conversation as it allows to flag messages in a 
way that is not only useful for a single reader, but for the whole community.
I don't know about Discourse, but, of course, it is possible to filter and sort 
data that is presented on a website, mark posts as read or ignore topics, 
threads or people (although I hope that won't be something common).
So if someone starts with chatter, the community can deal with that easily 
using tags, and the imho only drawback that isn't neutralised by the mail 
interface would be very small — assuming that the switch to an official forum 
would harm discipline at all (I doubt that).
It's also harder to send messages to a wrong recipient, accidentally create a 
new thread (both happen all the time with the mailing list) or create an 
infinity loop of "out of office"-mails (I guess Mailman is smart enough to deal 
with those).

Imho a mailing list is a good tool to organise communication of an established 
group, but fails when you want to build an vibrant, open community.
Most likely there aren't many people here that read every message, and I 
challenge everyone to ask yourself if you have "personal filters" like "body 
long, and no @apple.com -> ignore".
I surely have such a filter (luckily, it isn't very reliable ;-), but I don't 
think it's a good thing; I'd prefer not to distribute my attention based on the 
status of the author, but rather on the feedback of those who actually took the 
time to read the message.

The "elite" doesn't suffer from the current medium, but I hope they agree that 
the situation is very different for rookies, and that swift-evolution should 
try to embrace everyone who wants to help make Swift better.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Strings in Swift 4

[Erica Sadun via swift-evolution]

> On Feb 2, 2017, at 12:35 PM, Erica Sadun via swift-evolution 
>  wrote:
> 
> 
>> On Feb 2, 2017, at 8:58 AM, Jonathan Hull via swift-evolution 
>>  wrote:
>> 
>> Just out of curiosity, what are the use-cases for an infinite sequence (as 
>> opposed to a sequence which is bounded to the type’s representable values)?
>> 
>> Thanks,
>> Jon
> 
> Now that drop(while:) and prefix(while:) have dropped, they're a lot nicer 
> than having to do sequence(first: 1, next: { $0 + 1 })
> 
> -- E

Actually after thinking about that, I withdraw that suggestion.

-- E

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

Re: [swift-evolution] Strings in Swift 4

[Matthew Johnson via swift-evolution]

> On Feb 2, 2017, at 1:19 PM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
> on Thu Feb 02 2017, Matthew Johnson  wrote:
> 
>>> On Feb 2, 2017, at 9:45 AM, Dave Abrahams 
>> wrote:
>>> 
>>> 
>>> 
>>> 
>> 
>>> 
>>> On Feb 2, 2017, at 7:11 AM, Matthew Johnson >> > wrote:
>>> 
> 
>> 
>> Furthermore, we emphatically do *not* need to make the
>> distinction you claim between “infinite” and “incomplete” ranges,
>> which *is* needless hairsplitting.
> 
> Strongly disagree, unless you can describe the semantics of the type 
> WITHOUT giving it different semantics depending on how it is used.
 
 This is the point that convinced me.  I’m going to take a closer
 look at Brent’s `RangeExpression` design which I must admit I only
 skimmed in the earlier discussion.
>>> 
>>> We already have exactly this situation with CountableRange (which
>>> will merge with Range when conditional conformances land).  When
>>> used as a Collection, it means "every index value starting with the
>>> lowerBound and ending just before the upperBound".  When used for
>>> slicing, it means, roughly, "take every one of the collection's
>>> indices that are in bounds.”
>> 
>> I don’t see how the behavior of the following code means roughly “take
>> every one of the collection’s indices that are in bounds”.  Can you
>> elaborate?
>> 
>> let range = 0..<20
>> let array = [1, 2, 3]
>> let slice = array[range] // trap on index out of bounds
> 
> “Roughly” means “I'm leaving out the part that it's a precondition that
> any (explicit) bound must be a valid index in the collection.”  
> 
>>> These are not the same thing.  A collection's indices need not
>>> include every expressible value of the Index type between startIndex
>>> and endIndex.
>> 
>> Sure, but it does appear as if the behavior of slicing assumes that
>> the upper and lower bounds of the range provided are valid indices.
> 
> Properly stated, it's a precondition.  This is a design decision.  We could
> have made slicing lenient, like Python's:
> 
 [1, 2][50]
> 
 [1, 2][5:10]
> []
> 
> We thought that in Swift it was more important to catch potential errors
> than to silently accept
> 
>[1, 2][5..<10]
> 
> we still have the option to loosen slicing so it works that way, but I
> am not at all convinced it would be an improvement.

I agree with the current behavior as it’s consistent with indexing.

Lenient slicing is in the same space as lenient indexing.  It’s easy enough to 
add lenient wrappers around the standard library’s trapping implementation.

If we ever decided to have both variants one would have to include a label and 
I don’t think anybody would support labeling the trapping variant (for many 
reasons).

> 
>> Xiaodi had convinced me that a one-sided range must take a position on
>> whether or not it has an infinite upper bound in order to make sense,
>> but now you’ve changed my mind back.
> 
> Phew!  To be clear:
> 
>  A one-sided range is *partial*.  It *has no* upper bound.

Ha!  I actually used the term “partial range" earlier.  :)

The distinction between having an infinite upper bound and having no upper 
bound, but still conforming to `Sequence` is pretty subtle.  

Ultimately I think having a really good name (`RangeExpression`) that implies 
that the usage site determines the meaning is super important to making this 
work.  Kudos to whoever came up with that name!

> 
>>> The whole point of the name RangeExpression is to acknowledge this
>>> truth: ranges in Swift bits of syntax whose meaning is given partly
>>> by how they are used.
>> 
>> This makes sense and is roughly the position I started with.  I should
>> have read through the archives of this thread more before jumping into
>> the middle of the discussion - I was missing some important context.
>> I apologize for not doing so.
> 
> No apology needed.  I really appreciate how everyone on this list works
> hard to discover the underlying truth in Swift's design.  Without that
> kind of engagement, Swift would be far worse off.
> 
> Thanks, everybody

Agree.  And I really appreciate the willingness of the core team to spend 
valuable time engaging with the community and helping to illuminate the design. 
 You have all spent significantly more time thinking about the “underlying 
truth” of the design than the rest of us!  

> 
> -- 
> -Dave
> 
> ___
> 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] Strings in Swift 4

[Dave Abrahams via swift-evolution]

on Thu Feb 02 2017, Jonathan Hull  wrote:

> I really like the IncompleteRange/RangeExpression idea!
>
> I don’t think that IncompleteRange/RangeExpression should, by themselves, 
> conform to Sequence. It
> seems like necessary information is missing there.  Instead, there needs to 
> be a conditional
> conformance to Sequence based on another protocol that provides the natural 
> bounds for the Bound
> type.
>
> For example, what if we have another protocol:
>
>   protocol FiniteComparable : Comparable { //Any finite set which is 
> comparable will have a
> lowest value and a highest value...
>   static var lowestValue:Self {get}
>   static var highestValue:Self {get}
>   }
>
> Something like UInt would have a lowestValue of 0 and highestValue of 
> (UInt.max -1).  Then you could
> conditionally conform a RangeExpression where the Bounds are FiniteComparable 
> to Sequence.
>
> Now the behavior is consistent.  In the case of ‘array[0…]’ the array is 
> providing the missing upper
> bound.  In the case of ‘for n in 0…’ the conformance to FiniteComparable is 
> providing the bound (and
> it doesn’t trap, because it is enumerating all values IN that type above the 
> lower bound).
>
>   for n in UInt8(0)… {/* Will get called for every possible value of 
> UInt8 */}
>
> I agree that trapping when an infinite sequence of integers goes past the max 
> value is the only
> reasonable thing to do in that situation... but since we get to define the 
> bounds (and we have
> defined them in other cases to be the largest usable value), why not define 
> them the same way here
> (i.e. not infinite).  In this case, I don’t see the added value in making the 
> sequence infinite
> instead of just bounded by what the type can represent.  The only thing it 
> seems it adds is the
> trapping behavior.  With the natural bound, you can use things like filter on 
> partially defined
> ranges (which would trap if they are defined as infinite):
>
>   let odd:[UInt8] = (0…).filter({$0 & 1 != 0}) //returns an array of all 
> the odd UInt8

Why store them?  This is all the odd integers, and it traps only when
you exceed the machine's ability to express the values.

let odd = (0...).lazy.filter({$0 & 1 != 0}) 

If you really want a range that is limited to the Int8s, just use
Int8.max as your upper bound on a closed range.  That's exactly what
closed ranges and .max static properties are for. It's much better to
explicitly say, “I expect this range to stop” than for us to potentially
hide bugs by silently bounding the range at a value that depends on type
context.

-- 
-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, Matthew Johnson  wrote:

>> On Feb 2, 2017, at 9:45 AM, Dave Abrahams 
> wrote:
>> 
>> 
>> 
>> 
>
>> 
>> On Feb 2, 2017, at 7:11 AM, Matthew Johnson > > wrote:
>> 
 
> 
> Furthermore, we emphatically do *not* need to make the
> distinction you claim between “infinite” and “incomplete” ranges,
> which *is* needless hairsplitting.
 
 Strongly disagree, unless you can describe the semantics of the type 
 WITHOUT giving it different semantics depending on how it is used.
>>> 
>>> This is the point that convinced me.  I’m going to take a closer
>>> look at Brent’s `RangeExpression` design which I must admit I only
>>> skimmed in the earlier discussion.
>> 
>> We already have exactly this situation with CountableRange (which
>> will merge with Range when conditional conformances land).  When
>> used as a Collection, it means "every index value starting with the
>> lowerBound and ending just before the upperBound".  When used for
>> slicing, it means, roughly, "take every one of the collection's
>> indices that are in bounds.”
>
> I don’t see how the behavior of the following code means roughly “take
> every one of the collection’s indices that are in bounds”.  Can you
> elaborate?
>
> let range = 0..<20
> let array = [1, 2, 3]
> let slice = array[range] // trap on index out of bounds

“Roughly” means “I'm leaving out the part that it's a precondition that
any (explicit) bound must be a valid index in the collection.”  

>> These are not the same thing.  A collection's indices need not
>> include every expressible value of the Index type between startIndex
>> and endIndex.
>
> Sure, but it does appear as if the behavior of slicing assumes that
> the upper and lower bounds of the range provided are valid indices.

Properly stated, it's a precondition.  This is a design decision.  We could
have made slicing lenient, like Python's:

 >>> [1, 2][50]
 
 >>> [1, 2][5:10]
 []

We thought that in Swift it was more important to catch potential errors
than to silently accept

[1, 2][5..<10]

we still have the option to loosen slicing so it works that way, but I
am not at all convinced it would be an improvement.

> Xiaodi had convinced me that a one-sided range must take a position on
> whether or not it has an infinite upper bound in order to make sense,
> but now you’ve changed my mind back.

Phew!  To be clear:

  A one-sided range is *partial*.  It *has no* upper bound.

>> The whole point of the name RangeExpression is to acknowledge this
>> truth: ranges in Swift bits of syntax whose meaning is given partly
>> by how they are used.
>
> This makes sense and is roughly the position I started with.  I should
> have read through the archives of this thread more before jumping into
> the middle of the discussion - I was missing some important context.
> I apologize for not doing so.

No apology needed.  I really appreciate how everyone on this list works
hard to discover the underlying truth in Swift's design.  Without that
kind of engagement, Swift would be far worse off.

Thanks, everybody

-- 
-Dave

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

Re: [swift-evolution] Strings in Swift 4

[Erica Sadun via swift-evolution]

> On Feb 2, 2017, at 8:58 AM, Jonathan Hull via swift-evolution 
>  wrote:
> 
> Just out of curiosity, what are the use-cases for an infinite sequence (as 
> opposed to a sequence which is bounded to the type’s representable values)?
> 
> Thanks,
> Jon

Now that drop(while:) and prefix(while:) have dropped, they're a lot nicer than 
having to do sequence(first: 1, next: { $0 + 1 })

-- E


___
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, Nevin Brackett-Rozinsky  wrote:

> So, not to be “that guy”, but does anyone recall what the status of the
> actual *String* revamp for Swift 4 currently is?
>
> There was a lot of good discussion on the matter, and I want to make sure
> it hasn’t gotten lost or dropped.

Thanks for bringing the thread back to its focus!  Nothing's been
dropped.  Part of the reason we published the manifesto was so that we
could gather feedback from the community.  The whole discussion is
archived, and we've been taking notes.

I would be very interested in any further discussion of Strings, if
there's anything left to discuss.

-- 
-Dave

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

Re: [swift-evolution] Subclass Existentials

[Douglas Gregor via swift-evolution]

> 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.

- Doug


> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 2. Februar 2017 um 05:52:41, Douglas Gregor via swift-evolution 
> (swift-evolution@swift.org ) schrieb:
> 
>> 
>> 
>> Sent from my iPhone
>> 
>> On Feb 1, 2017, at 8:46 PM, Slava Pestov > > wrote:
>> 
>>> 
 On Feb 1, 2017, at 4:09 PM, Douglas Gregor via swift-evolution 
 > wrote:
 
> 
> On Feb 1, 2017, at 3:13 PM, David Hart  > wrote:
> 
> Second question inline:
> 
> 
> 
> Sent from my iPhone
> On 1 Feb 2017, at 23:09, David Hart  > wrote:
> 
>> I did consider it, but didn’t want to put too much on your plate for 
>> Swift 4. But if you’re mentioning it, I’ll go ahead and add it to the 
>> second version of the proposal.
>> 
>> By the way, what you is your point of view about the discussions we’ve 
>> had concerning the positioning of the class constraint?
>> 
>> David.
>> 
>>> On 1 Feb 2017, at 22:58, Douglas Gregor >> > wrote:
>>> 
>>> 
 On Jan 29, 2017, at 8:39 AM, David Hart > wrote:
 
 Hello,
 
 As promised, I wrote the first draft of a proposal to add class 
 requirements to the existential syntax. Please let me know what you 
 think.
 
 https://github.com/hartbit/swift-evolution/blob/subclass-existentials/proposals/-subclass-existentials.md
  
 
>>> This looks good! I’m looking forward to the second draft, but I have 
>>> one question.
>>> 
>>> Did you consider the generalized “class” constraint? IIRC, this was in 
>>> Austin’s larger proposal, and it allowed for (e.g.)
>>> 
>>> typealias CustomStringConvertibleClass = class & 
>>> CustomStringConvertible// class that conforms to 
>>> CustomStringConvertible
>>> 
>>> and potentially a wonderful cleanup where AnyObject ceases to be a 
>>> weird special protocol and instead 

Re: [swift-evolution] Default Generic Arguments

[Alexis via swift-evolution]

> On Jan 27, 2017, at 4:43 PM, Anton Zhilin via swift-evolution 
>  wrote:
> 
> Current alternative to default generic arguments is typealias, like 
> basic_string and string in C++:
> 
> struct BasicBigInt { ... }
> typealias BigInt = BasicBigInt
This is a really great point, but it should be noted that this is only 
sufficient to accomplish source-stability. Once the standard library starts 
providing ABI stability, this solution won’t work for it — the type of BigInt 
will become BasicBigInt which will change mangling and other things. 

First-class generic defaults, on the other hand, have the potential to be built 
out so that any binary compiled against the old type definition continues to 
work. The details of what this looks like depends on precisely how the final 
ABI shakes out.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

> On Feb 1, 2017, at 4:34 AM, David Hart via swift-evolution 
>  wrote:
> 
> 
> 
> On 1 Feb 2017, at 06:59, Thorsten Seitz via swift-evolution 
> > wrote:
> 
>> While I'm not really happy with the mailing list, this is mostly due to 
>> restrictions of iOS Mail which makes keeping track of relevant threads and 
>> filtering out threads I'm not interested in difficult.
>> 
>> The mailing list has one important advantage over a web interface: most of 
>> my reading happens on a train to and from work. On this train the connection 
>> is for most parts of the ride so bad that I can't download new messages, but 
>> fortunately that is not necessary because I can read all those messages I 
>> downloaded earlier on the railway station.
>> With a web interface I expect that to be much more problematic because it 
>> would have to download each message or maybe at least each thread on demand.
> 
> Discourse has a mailing list mode to have send you and accept email replies. 
> You'd be covered.
> 

Discourse has the outward appearance of a forum. Because of that, it will 
naturally adopt the social behaviors typical of a forum. In forums, light back 
and forth is common, and there's no way for mods to "remove" messages from 
having been emailed out. Natural forum-like idle chatter can overwhelm the 
traffic of those of us who prefer mailing list mode so we can sort, track, 
flag, and filter the on-list conversations.  To get a sense, check out the 
traffic on https://swift-lang.slack.com  and 
https://iosdevelopers.slack.com .

A mailing list discourages off-topic and trivial contributions.  I could easily 
see being sent dozens of emails from a single back and forth.  Increased 
traffic would force most users to migrate from email to direct Discourse forums 
and direct forum use loses the ability to flag, filter, and sort discussions. 
You can't scan, mark, and put away threads you've already dealt with. This 
would be a massive loss of utility for those of us who need to keep on top of 
language discussions for work.

I do prefer upgrading to Mailman 3.

-- E

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

Re: [swift-evolution] Annotation of Warnings/Errors

[Pierre Monod-Broca via swift-evolution]

+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 
>  a écrit :
> 
> +1
> 
> On Tue, Jan 31, 2017 at 11:55 AM, Tino Heth via swift-evolution 
>  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

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

[Michael Buckley via swift-evolution]

This morning I received an email from Discourse titled "[Swift Discussions
(Unofficial Test)] Summary". Since this message was sent to my email
address personally, rather than to the swift-evolution address, it appears
that my email address was exported from this list and imported into
Discourse.

At this point, no harm done. This is obviously a self-hosted temporary
Discourse install hosted on Nate's own server. However, I am worried about
how my email address was added to the temporary Discord. I get that this
mailing list can be viewed by anyone, and only slightly obfuscates our
email addresses. Anyone motivated enough can scrape all the email
addresses, but there's a difference between that and Apple handing my email
address to a third party which I may or may not be OK with having it, even
if it's a member of this community.

That's not to say anything bad about Discourse, or to argue one way or
another about whether to move the mailing list, but when I signed up for
swift-evolution, I trusted my email address to Apple for this purpose. It
may be misplaced, but I feel I can trust Apple to not use the email address
for any other purpose, and to keep their servers relatively secure so that
the subscribers list won't leak (again, with the exception of scraping the
addresses).

If Apple ends up hosting its own Discourse server, I won't have any
complaints. But if the decision is made to have it hosted externally, or
another service is chosen, I do not want my email address to be
automatically transferred to the new system. I would like the ability to
chose for myself at that time whether I want to subscribe.

On Thu, Jan 26, 2017 at 10:02 AM, Nate Cook via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Jan 25, 2017, at 3:32 PM, Douglas Gregor via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On Jan 25, 2017, at 12:05 PM, Ted Kremenek via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I have no problem with the project moving to forums instead of the Mailman
> mailing lists we have now — if it is the right set of tradeoffs.
>
> My preference is to approach the topic objectively, working from goals and
> seeing how the mailing lists are aligning with those goals and how an
> alternative, such as Discourse, might do a better job.
>
> The current use of mailing lists has been carry-over of how both LLVM does
> public discussion (which is all mailing lists) and how the Swift team at
> Apple has used mailing lists for discussion.  That inertia has benefits in
> that it is a familiar workflow that is “proven” to work — but the doesn’t
> mean it is the best option going forward.
>
> Here are some of the things that matter to me:
>
> - Topics are easy to manage and search, with stable URLs for archives.
>
> - It is easy to reference other topics with a stable (canonical) URL that
> allows you to jump into that other topic easily.  That’s hard to do if you
> haven’t already been subscribed to the list.
>
> - Works fine with email clients, for those who want to keep that workflow
> (again this inertia is important).
>
> - Code formatting, and other tools that add clarity in communication, are
> a huge plus.
>
> I’d like to understand more the subjective comments on this thread, such
> as "may intimidate newcomers”.  This feels very subjective, and while I am
> not disagreeing with that statement I don’t fully understand its
> justification.  Signing up for mailing lists is fairly straightforward, and
> one isn’t obligated to respond to threads.  Are forums really any less
> “intimating”? If so, why is that the case?  Is this simply a statement
> about mailing lists not being in vogue?
>
> I do also think the asynchronous nature of the mailing lists is important,
> as opposed to discussions feeling like a live chat.  Live chat, such as the
> use of Slack the SwiftPM folks have been using, is very useful too, but I
> don’t want participants on swift-evolution or any of our mailing lists feel
> obligated to respond in real time — that’s simply not the nature of the
> communication on the lists.
>
> So in short, using mailing lists specifically is not sacred — we can
> change what we use for our community discussions.  I just want an objective
> evaluation of the needs the mailing lists are meant to serve, and work from
> there.  If moving to something like (say) Discourse would be a negative on
> a critical piece that is well-served by the mailing lists, that would (in
> my opinion) a bad direction to take.  I’m not saying that is the case, just
> that this is how I prefer we approach the discussion.
>
>
> I’ve looked into Discourse a bit, and it does look very promising. One
> *specific* way in which a motivated individual could help would be to take
> a look at Discourse’s import scripts
>  and
> try importing swift-evolution’s mailing archives with them. We absolutely
> do not want to lose history when we 

Re: [swift-evolution] Strings in Swift 4

[Matthew Johnson via swift-evolution]

> On Feb 2, 2017, at 9:45 AM, Dave Abrahams  wrote:
> 
> 
> 
> Sent from my iPad
> 
> On Feb 2, 2017, at 7:11 AM, Matthew Johnson  > wrote:
> 
>>> 
 
 Furthermore, we emphatically do *not* need to make the distinction you 
 claim between “infinite” and “incomplete” ranges, which *is* needless 
 hairsplitting.
>>> 
>>> Strongly disagree, unless you can describe the semantics of the type 
>>> WITHOUT giving it different semantics depending on how it is used.
>> 
>> This is the point that convinced me.  I’m going to take a closer look at 
>> Brent’s `RangeExpression` design which I must admit I only skimmed in the 
>> earlier discussion.
> 
> We already have exactly this situation with CountableRange (which will merge 
> with Range when conditional conformances land).  When used as a Collection, 
> it means "every index value starting with the lowerBound and ending just 
> before the upperBound".  When used for slicing, it means, roughly, "take 
> every one of the collection's indices that are in bounds.”  

I don’t see how the behavior of the following code means roughly “take every 
one of the collection’s indices that are in bounds”.  Can you elaborate?

let range = 0..<20
let array = [1, 2, 3]
let slice = array[range] // trap on index out of bounds

> These are not the same thing.  A collection's indices need not include every 
> expressible value of the Index type between startIndex and endIndex.

Sure, but it does appear as if the behavior of slicing assumes that the upper 
and lower bounds of the range provided are valid indices.  

Xiaodi had convinced me that a one-sided range must take a position on whether 
or not it has an infinite upper bound in order to make sense, but now you’ve 
changed my mind back.

> 
> The whole point of the name RangeExpression is to acknowledge this truth: 
> ranges in Swift bits of syntax whose meaning is given partly by how they are 
> used.  

This makes sense and is roughly the position I started with.  I should have 
read through the archives of this thread more before jumping into the middle of 
the discussion - I was missing some important context.  I apologize for not 
doing so.

The name `RangeExpression` does a good job of indicating why it’s ok for 
instances to sometimes behave as if they have an infinite upper bound and other 
times not depending on context.


> In fact, now that I say it, in that respect ranges are not all that different 
> any other type: the meaning of a Double or an Array or a Bool is also 
> interpreted by the methods to which it is passed, and can have completely 
> different results depending on that context.
> 
> chillaxing-ly y'rs,
> 
> Dave

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

Re: [swift-evolution] Strings in Swift 4

[Nevin Brackett-Rozinsky via swift-evolution]

So, not to be “that guy”, but does anyone recall what the status of the
actual *String* revamp for Swift 4 currently is?

There was a lot of good discussion on the matter, and I want to make sure
it hasn’t gotten lost or dropped.

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

Re: [swift-evolution] Strings in Swift 4

[Jonathan Hull via swift-evolution]

Just out of curiosity, what are the use-cases for an infinite sequence (as 
opposed to a sequence which is bounded to the type’s representable values)?

Thanks,
Jon

> On Feb 2, 2017, at 7:52 AM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
> 
> Sent from my iPad
> 
> On Feb 2, 2017, at 7:32 AM, Matthew Johnson  > wrote:
> 
>> 
>>> On Feb 2, 2017, at 6:07 AM, Brent Royal-Gordon via swift-evolution 
>>> > wrote:
>>> 
 On Feb 2, 2017, at 3:06 AM, Jaden Geller via swift-evolution 
 > wrote:
 
 It's not infinite (else subscript would trap)
>>> 
>>> I'm not necessarily a fan of the idea of allowing you to iterate over an 
>>> `IncompleteRange`, but I have to ask: What do you imagine an infinite 
>>> sequence of integers would do when it tried to go past the `max` value? As 
>>> far as I can tell, trapping is the *only* sensible possibility.
>> 
>> I don’t think anyone is disputing this right now.  The discussion is whether 
>> `IncompleteRange` and `InfiniteRange` are distinct concepts which should be 
>> modeled or whether they can be adequately represented by a single type.
>> 
>> In order to iterate a range you must know both bounds (even if one is 
>> infinite).  When we have a one-sided range with a bound that is countable 
>> and we allow it to conform to Sequence we are implicitly acknowledging it is 
>> an infinite range rather than an “incomplete” range.
>> 
>> If you have a range with an infinite upper bound (i.e. a one-sided range 
>> with a countable Bound) and apply the usual semantics of a collection 
>> subscript operation the result would necessarily trap because the upper 
>> bound is out of bounds.
>> 
>> We obviously don’t want this behavior.  Instead we want the upper bound to 
>> be clamped to the index preceding `endIndex` as a part of the subscript 
>> operation. For an infinite range this is equivalent to a very special case 
>> clamping behavior.  Special case clamping behavior like this is questionable 
>> on its own, and especially questionable if we ever add `InfiniteCollection` 
>> (which Ben mentioned in a footnote to his post) where subscripting with an 
>> infinite range would be a perfectly valid operation that produces an 
>> infinite slice.
>> 
>> If instead, we have a distinct type for `IncompleteRange` we don’t need a 
>> subscript overload with this kind of special case behavior.  There would not 
>> be a subscript that accepts `InfiniteRange` at all (for now - if we add 
>> `InfiniteCollection` later it probably *would* have one).  Instead, we would 
>> have a subscript that accepts `IncompleteRange` with the obvious semantics 
>> of filling in the missing bound with the last valid index (or `startIndex` 
>> if we also support incomplete ranges that only specify an upper bound).
> 
> The difference between Range and CountableRange (which I'm desperate to 
> eliminate using conditional conformances) has already been a source of deep 
> frustration for many users.  From a pure usability standpoint the idea of 
> creating more distinctions in the type system between similar ranges is 
> unfathomable to me.  Doing so on grounds like those described above seems 
> like it would represent a blatant case of theoretical purity winning out over 
> practical considerations, which runs counter to the spirit of Swift.
> 
> --Dave
> ___
> 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] Strings in Swift 4

[Dave Abrahams via swift-evolution]

Sent from my iPad

> On Feb 2, 2017, at 7:32 AM, Matthew Johnson  wrote:
> 
> 
>>> On Feb 2, 2017, at 6:07 AM, Brent Royal-Gordon via swift-evolution 
>>>  wrote:
>>> 
>>> On Feb 2, 2017, at 3:06 AM, Jaden Geller via swift-evolution 
>>>  wrote:
>>> 
>>> It's not infinite (else subscript would trap)
>> 
>> I'm not necessarily a fan of the idea of allowing you to iterate over an 
>> `IncompleteRange`, but I have to ask: What do you imagine an infinite 
>> sequence of integers would do when it tried to go past the `max` value? As 
>> far as I can tell, trapping is the *only* sensible possibility.
> 
> I don’t think anyone is disputing this right now.  The discussion is whether 
> `IncompleteRange` and `InfiniteRange` are distinct concepts which should be 
> modeled or whether they can be adequately represented by a single type.
> 
> In order to iterate a range you must know both bounds (even if one is 
> infinite).  When we have a one-sided range with a bound that is countable and 
> we allow it to conform to Sequence we are implicitly acknowledging it is an 
> infinite range rather than an “incomplete” range.
> 
> If you have a range with an infinite upper bound (i.e. a one-sided range with 
> a countable Bound) and apply the usual semantics of a collection subscript 
> operation the result would necessarily trap because the upper bound is out of 
> bounds.
> 
> We obviously don’t want this behavior.  Instead we want the upper bound to be 
> clamped to the index preceding `endIndex` as a part of the subscript 
> operation. For an infinite range this is equivalent to a very special case 
> clamping behavior.  Special case clamping behavior like this is questionable 
> on its own, and especially questionable if we ever add `InfiniteCollection` 
> (which Ben mentioned in a footnote to his post) where subscripting with an 
> infinite range would be a perfectly valid operation that produces an infinite 
> slice.
> 
> If instead, we have a distinct type for `IncompleteRange` we don’t need a 
> subscript overload with this kind of special case behavior.  There would not 
> be a subscript that accepts `InfiniteRange` at all (for now - if we add 
> `InfiniteCollection` later it probably *would* have one).  Instead, we would 
> have a subscript that accepts `IncompleteRange` with the obvious semantics of 
> filling in the missing bound with the last valid index (or `startIndex` if we 
> also support incomplete ranges that only specify an upper bound).

The difference between Range and CountableRange (which I'm desperate to 
eliminate using conditional conformances) has already been a source of deep 
frustration for many users.  From a pure usability standpoint the idea of 
creating more distinctions in the type system between similar ranges is 
unfathomable to me.  Doing so on grounds like those described above seems like 
it would represent a blatant case of theoretical purity winning out over 
practical considerations, which runs counter to the spirit of Swift.

--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]

Sent from my iPad

> On Feb 2, 2017, at 7:11 AM, Matthew Johnson  wrote:
> 
>>> 
>>> 
>>> Furthermore, we emphatically do *not* need to make the distinction you 
>>> claim between “infinite” and “incomplete” ranges, which *is* needless 
>>> hairsplitting.
>> 
>> Strongly disagree, unless you can describe the semantics of the type WITHOUT 
>> giving it different semantics depending on how it is used.
> 
> This is the point that convinced me.  I’m going to take a closer look at 
> Brent’s `RangeExpression` design which I must admit I only skimmed in the 
> earlier discussion.

We already have exactly this situation with CountableRange (which will merge 
with Range when conditional conformances land).  When used as a Collection, it 
means "every index value starting with the lowerBound and ending just before 
the upperBound".  When used for slicing, it means, roughly, "take every one of 
the collection's indices that are in bounds."  These are not the same thing.  A 
collection's indices need not include every expressible value of the Index type 
between startIndex and endIndex.

The whole point of the name RangeExpression is to acknowledge this truth: 
ranges in Swift bits of syntax whose meaning is given partly by how they are 
used.  In fact, now that I say it, in that respect ranges are not all that 
different any other type: the meaning of a Double or an Array or a Bool 
is also interpreted by the methods to which it is passed, and can have 
completely different results depending on that context.

chillaxing-ly y'rs,

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

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

[Jonathan Hull via swift-evolution]

> On Feb 2, 2017, at 6:11 AM, David Hart via swift-evolution 
>  wrote:
> 
>> 
>> On 2 Feb 2017, at 14:52, Derrick Ho via swift-evolution 
>> > wrote:
>> 
>> Shouldn't NSUInteger always become UInt in swift?
> 
> Jordan answers this question in his email:
> 
> 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?

What if we import it as UInt, but have an annotation that the frameworks can 
add saying that it should be imported as Int instead?  Then have a bot apply 
that annotation to the system frameworks where it would import it as Int in the 
current system.  Then there are no source breaking changes (beyond frameworks 
where you explicitly choose to remove the annotation because the breaking 
change is considered better than the status quo).

Thanks,
Jon___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Strings in Swift 4

[Matthew Johnson via swift-evolution]

> On Feb 2, 2017, at 6:07 AM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>> On Feb 2, 2017, at 3:06 AM, Jaden Geller via swift-evolution 
>>  wrote:
>> 
>> It's not infinite (else subscript would trap)
> 
> I'm not necessarily a fan of the idea of allowing you to iterate over an 
> `IncompleteRange`, but I have to ask: What do you imagine an infinite 
> sequence of integers would do when it tried to go past the `max` value? As 
> far as I can tell, trapping is the *only* sensible possibility.

I don’t think anyone is disputing this right now.  The discussion is whether 
`IncompleteRange` and `InfiniteRange` are distinct concepts which should be 
modeled or whether they can be adequately represented by a single type.

In order to iterate a range you must know both bounds (even if one is 
infinite).  When we have a one-sided range with a bound that is countable and 
we allow it to conform to Sequence we are implicitly acknowledging it is an 
infinite range rather than an “incomplete” range.

If you have a range with an infinite upper bound (i.e. a one-sided range with a 
countable Bound) and apply the usual semantics of a collection subscript 
operation the result would necessarily trap because the upper bound is out of 
bounds.

We obviously don’t want this behavior.  Instead we want the upper bound to be 
clamped to the index preceding `endIndex` as a part of the subscript operation. 
For an infinite range this is equivalent to a very special case clamping 
behavior.  Special case clamping behavior like this is questionable on its own, 
and especially questionable if we ever add `InfiniteCollection` (which Ben 
mentioned in a footnote to his post) where subscripting with an infinite range 
would be a perfectly valid operation that produces an infinite slice.

If instead, we have a distinct type for `IncompleteRange` we don’t need a 
subscript overload with this kind of special case behavior.  There would not be 
a subscript that accepts `InfiniteRange` at all (for now - if we add 
`InfiniteCollection` later it probably *would* have one).  Instead, we would 
have a subscript that accepts `IncompleteRange` with the obvious semantics of 
filling in the missing bound with the last valid index (or `startIndex` if we 
also support incomplete ranges that only specify an upper bound).

> 
> (If you used a `BigInt` type, the sequence could of course then be infinite, 
> or as infinite as memory allows.)
> 
> -- 
> 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] Strings in Swift 4

[Jonathan Hull via swift-evolution]

I really like the IncompleteRange/RangeExpression idea!

I don’t think that IncompleteRange/RangeExpression should, by themselves, 
conform to Sequence. It seems like necessary information is missing there.  
Instead, there needs to be a conditional conformance to Sequence based on 
another protocol that provides the natural bounds for the Bound type.

For example, what if we have another protocol:

protocol FiniteComparable : Comparable { //Any finite set which is 
comparable will have a lowest value and a highest value...
static var lowestValue:Self {get}
static var highestValue:Self {get}
}

Something like UInt would have a lowestValue of 0 and highestValue of (UInt.max 
-1).  Then you could conditionally conform a RangeExpression where the Bounds 
are FiniteComparable to Sequence.

Now the behavior is consistent.  In the case of ‘array[0…]’ the array is 
providing the missing upper bound.  In the case of ‘for n in 0…’ the 
conformance to FiniteComparable is providing the bound (and it doesn’t trap, 
because it is enumerating all values IN that type above the lower bound).

for n in UInt8(0)… {/* Will get called for every possible value of 
UInt8 */}


I agree that trapping when an infinite sequence of integers goes past the max 
value is the only reasonable thing to do in that situation... but since we get 
to define the bounds (and we have defined them in other cases to be the largest 
usable value), why not define them the same way here (i.e. not infinite).  In 
this case, I don’t see the added value in making the sequence infinite instead 
of just bounded by what the type can represent.  The only thing it seems it 
adds is the trapping behavior.  With the natural bound, you can use things like 
filter on partially defined ranges (which would trap if they are defined as 
infinite):

let odd:[UInt8] = (0…).filter({$0 & 1 != 0}) //returns an array of all 
the odd UInt8

In cases where the bound type doesn’t conform to FiniteComparable, it could 
still be used as a RangeExpression, but not as a sequence.

Thanks,
Jon


> On Feb 2, 2017, at 4:07 AM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>> On Feb 2, 2017, at 3:06 AM, Jaden Geller via swift-evolution 
>>  wrote:
>> 
>> It's not infinite (else subscript would trap)
> 
> I'm not necessarily a fan of the idea of allowing you to iterate over an 
> `IncompleteRange`, but I have to ask: What do you imagine an infinite 
> sequence of integers would do when it tried to go past the `max` value? As 
> far as I can tell, trapping is the *only* sensible possibility.
> 
> (If you used a `BigInt` type, the sequence could of course then be infinite, 
> or as infinite as memory allows.)
> 
> -- 
> 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 seed: gathering data to fix the NSUInteger inconsistency

[David Hart via swift-evolution]

> On 2 Feb 2017, at 14:52, Derrick Ho via swift-evolution 
>  wrote:
> 
> Shouldn't NSUInteger always become UInt in swift?

Jordan answers this question in his email:

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?

> On Thu, Feb 2, 2017 at 12:07 AM Freak Show via swift-evolution 
> > wrote:
> I have a framework I wrote that maps Objective C objects to sqlite records - 
> deriving sqlite schema definitions from property definitions.  You simply 
> derive model classes from my base class Model and the base class will 
> introspect the properties and handle all the sql for you.  A little like 
> CoreData but the property definitions are used for the meta model instead of 
> an external model file and it is a lot leaner and natural feeling.
> 
> I picked NSUInteger for the auto incremented primary key because, after all, 
> it would never go negative.
> 
> However, when I tried to import this framework into Swift and use Model as a 
> base class for a Swift class, I found it nearly impossible to satisfy the 
> compiler about mixed mode comparisons and ultimately changed the type to 
> NSInteger.  
> 
> I was not happy about it and if I wasn't the framework author I would have 
> thought harder about changing it.
> 
> 
> 
> 
>> On Feb 1, 2017, at 17:29, Jordan Rose via swift-evolution 
>> > wrote:
>> 
>> find out how Objective-C projects are using NSUInteger in their headers:
>> 
>> - Do they have no NSUIntegers at all?
>> - Are they using NSUInteger because they’re overriding something that used 
>> NSUInteger, or implementing a protocol method that used NSUInteger?
>> - Are they using NSUInteger as an opaque value, where comparisons and 
>> arithmetic are uninteresting?
>> - Are they using NSUInteger as an index or count of something held in memory?
> 
> ___
> 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] Proposal seed: gathering data to fix the NSUInteger inconsistency

[Derrick Ho via swift-evolution]

Shouldn't NSUInteger always become UInt in swift?
On Thu, Feb 2, 2017 at 12:07 AM Freak Show via swift-evolution <
swift-evolution@swift.org> wrote:

> I have a framework I wrote that maps Objective C objects to sqlite records
> - deriving sqlite schema definitions from property definitions.  You simply
> derive model classes from my base class Model and the base class will
> introspect the properties and handle all the sql for you.  A little like
> CoreData but the property definitions are used for the meta model instead
> of an external model file and it is a lot leaner and natural feeling.
>
> I picked NSUInteger for the auto incremented primary key because, after
> all, it would never go negative.
>
> However, when I tried to import this framework into Swift and use Model as
> a base class for a Swift class, I found it nearly impossible to satisfy the
> compiler about mixed mode comparisons and ultimately changed the type to
> NSInteger.
>
> I was not happy about it and if I wasn't the framework author I would have
> thought harder about changing it.
>
>
>
>
> On Feb 1, 2017, at 17:29, Jordan Rose via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> *find out how Objective-C projects are using NSUInteger in their headers:*
>
> - Do they have no NSUIntegers at all?
> - Are they using NSUInteger because they’re overriding something that used
> NSUInteger, or implementing a protocol method that used NSUInteger?
> - Are they using NSUInteger as an opaque value, where comparisons and
> arithmetic are uninteresting?
> - Are they using NSUInteger as an index or count of something held in
> memory?
>
>
> ___
> 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] for-else syntax

[Derrick Ho via swift-evolution]

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
})
On Thu, Feb 2, 2017 at 6:31 AM Haravikk via swift-evolution <
swift-evolution@swift.org> 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 <
> swift-evolution@swift.org> wrote:
>
>
> On 1 Feb 2017, at 18:29, Chris Davis via swift-evolution <
> swift-evolution@swift.org> 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 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-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] [draft] Compound Names For Enum Cases

[Adrian Zubarev via swift-evolution]

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
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] [draft] Compound Names For Enum Cases

[Daniel Duan via swift-evolution]

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
>> 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] Strings in Swift 4

[Brent Royal-Gordon via swift-evolution]

> On Feb 2, 2017, at 3:06 AM, Jaden Geller via swift-evolution 
>  wrote:
> 
> It's not infinite (else subscript would trap)

I'm not necessarily a fan of the idea of allowing you to iterate over an 
`IncompleteRange`, but I have to ask: What do you imagine an infinite sequence 
of integers would do when it tried to go past the `max` value? As far as I can 
tell, trapping is the *only* sensible possibility.

(If you used a `BigInt` type, the sequence could of course then be infinite, or 
as infinite as memory allows.)

-- 
Brent Royal-Gordon
Architechies

___
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]

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 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-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] for-else syntax

[Jeremy Pereira via swift-evolution]

> 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 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-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] for-else syntax

[Nicolas Fezans via swift-evolution]

While I understand that there is a rationale behind "NonEmptyArray", I
don't think that this applies to the original question of Chris.
It seems that it is fully acceptable for the array to be empty in the
considered case, but only some different treatment shall happen in that
case.

I could easily imagine that situation when querying a database: you do not
want to specify that the query have no answer, but in one case you might
want to iterate through the items matching you query and do something with
them whereas in the other case you might want to notify the user that there
were no match.

Nicolas

On Wed, Feb 1, 2017 at 10:46 PM, Charlie Monroe 
wrote:

> +1
>
> This is generally why I've suggested about a week or two ago
> "NonEmptyArray" - an array that ensures it's not empty. Which is IMHO a
> sensible thing to use sometimes instead...
>
> > On Feb 1, 2017, at 8:38 PM, Sean Heber via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > I usually use guard (or sometimes if) and an early return:
> >
> > func run() {
> >  guard !names.isEmpty else {
> >/* stuff */
> >return
> >  }
> >
> >  /* stuff with names */
> > }
> >
> > l8r
> > Sean
> >
> >
> >
> >> On Feb 1, 2017, at 12:18 PM, Nicolas Fezans via swift-evolution <
> swift-evolution@swift.org> 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
> >>  }
> >> }
> >>
> >>
> >> Nicolas Fezans
> >>
> >>
> >>
> >> On Wed, Feb 1, 2017 at 6:31 PM, Saagar Jha via swift-evolution <
> swift-evolution@swift.org> wrote:
> >> If you’re fine with a couple extra characters, you can use .isEmpty:
> >>
> >> for name in names {
> >>  // do your thing
> >> }
> >> if names.isEmpty {
> >>  // do whatever
> >> }
> >>
> >> It’s a bit more typing, but I feel it makes your intentions more clear.
> >>
> >> Saagar Jha
> >>
> >>> On Feb 1, 2017, at 8:48 AM, Chris Davis via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>>
> >>> Hi,
> >>>
> >>> Often when I’m programming I stumble upon this scenario:
> >>>
> >>> I have a list of items that may or may not be empty - if it’s full, I
> do one thing, if it’s empty I do something else, my code looks like this:
> >>>
> >>> class Example_1
> >>> {
> >>>let names = ["Chris", "John", "Jordan"]
> >>>
> >>>/// Loop over names, if no names, print no names
> >>>func run()
> >>>{
> >>>for name in names
> >>>{
> >>>print(name)
> >>>}
> >>>
> >>>if names.count == 0
> >>>{
> >>>print("no names")
> >>>}
> >>>}
> >>> }
> >>>
> >>> let exampleOne = Example_1()
> >>> exampleOne.run()
> >>>
> >>> However, Personally, I would find it more pleasing to write something
> like this:
> >>>
> >>> class Example_2_Proposed
> >>> {
> >>>let names:[String] = []
> >>>
> >>>/// Loop over names, if no names, print no names
> >>>func run()
> >>>{
> >>>for name in names
> >>>{
> >>>print(name)
> >>>} else {
> >>>print("no names")
> >>>}
> >>>}
> >>> }
> >>>
> >>> let exampleTwo = Example_2_Proposed()
> >>> exampleTwo.run()
> >>>
> >>> The difference here is a “for-else” type syntax where if there were no
> items in the array it would simply fall through to the else statement.
> >>>
> >>> What would be the pros/cons of introducing such syntax?
> >>>
> >>> Is there’s a way of doing something similar in swift already?
> >>>
> >>> Thanks
> >>>
> >>> Chris
> >>>
> >>>
> >>>
> >>>
> >>> ___
> >>> 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
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Subclass Existentials

[Jaden Geller via swift-evolution]

It's pretty bizarre that conforming to `protocol P: Q {}` requires an explicit 
conformance to Q when Q is a class but not when Q is a protocol. It's the same 
syntax, but conformance is only "inherited" for protocols.

> On Feb 1, 2017, at 3:47 PM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> 
> 
> Sent from my iPad
> 
>> On Feb 1, 2017, at 5:11 PM, David Sweeris via swift-evolution 
>>  wrote:
>> 
>> 
>>> On Feb 1, 2017, at 3:01 PM, David Hart via swift-evolution 
>>>  wrote:
>>> 
>>> 
>>> On 1 Feb 2017, at 22:54, Douglas Gregor  wrote:
>>> 
 
> On Jan 29, 2017, at 8:44 PM, Slava Pestov via swift-evolution 
>  wrote:
> 
> This is a nice generalization of the existing protocol composition 
> syntax. Implementation might get a little tricky — this touches a lot of 
> things, such as inheritance clauses, constraints in generic signatures, 
> and casts. It would require thorough testing.
> 
> There are also a few odd corner cases to sort out:
> 
> typealias T = SomeClass & SomeProtocol
> 
> class C : T { // should we allow this? probably yes
> }
> 
> protocol P : T { // should we allow this? probably no
> }
 
 IIRC, we already allow the latter where T is a typealias for SomeProtocol1 
 & SomeProtocol2. Why not allow it generally?
>>> 
>>> Well what would it mean? A protocol can't inherit or conform to a class.
>> 
>> That anything which conforms to that protocol must subclass SomeClass?
> 
> Yes, this is exactly what I would expect.  I was calling it a supertype 
> requirement earlier in the thread.
> 
>> 
>> - Dave Sweeris
>> ___
>> 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] [draft] Compound Names For Enum Cases

[Adrian Zubarev via swift-evolution]

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
https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution