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

> 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

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

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

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

> 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

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

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

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

> 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

Re: [swift-evolution] Removing enumerated?

> 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

Re: [swift-evolution] Removing enumerated?

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

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

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

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

(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

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

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.

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

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

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

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

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

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

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

> 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

Re: [swift-evolution] Strings in Swift 4

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

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

> 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

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

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),

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

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,

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

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

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

> 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

Re: [swift-evolution] Subclass Existentials

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

Re: [swift-evolution] Subclass Existentials

> 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

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

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

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

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

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

> 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

Re: [swift-evolution] Strings in Swift 4

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*

Re: [swift-evolution] Either protocol syntax

> 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

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

> 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

Re: [swift-evolution] Either protocol syntax

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

Re: [swift-evolution] Either protocol syntax

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

Re: [swift-evolution] Either protocol syntax

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

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

> 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

Re: [swift-evolution] Either protocol syntax

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

Re: [swift-evolution] Either protocol syntax

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

[swift-evolution] Either protocol syntax

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

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

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

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

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

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

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

Re: [swift-evolution] Strings in Swift 4

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

Re: [swift-evolution] Strings in Swift 4

> 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

Re: [swift-evolution] Strings in Swift 4

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,

Re: [swift-evolution] Strings in Swift 4

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

Re: [swift-evolution] Strings in Swift 4

> 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

Re: [swift-evolution] Strings in Swift 4

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

Re: [swift-evolution] Subclass Existentials

> 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

Re: [swift-evolution] Default Generic Arguments

> 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

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

> 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

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

+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

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

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.

Re: [swift-evolution] Strings in Swift 4

> 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

Re: [swift-evolution] Strings in Swift 4

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 ___

Re: [swift-evolution] Strings in Swift 4

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 >

Re: [swift-evolution] Strings in Swift 4

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

Re: [swift-evolution] Strings in Swift 4

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

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

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

Re: [swift-evolution] Strings in Swift 4

> 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

Re: [swift-evolution] Strings in Swift 4

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

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

> 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

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

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

Re: [swift-evolution] for-else syntax

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

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

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

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

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

Re: [swift-evolution] Strings in Swift 4

> 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

Re: [swift-evolution] for-else syntax

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

Re: [swift-evolution] for-else syntax

> 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

Re: [swift-evolution] for-else syntax

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

Re: [swift-evolution] Subclass Existentials

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 >

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

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