Re: [swift-evolution] [swift-dev] RFC: bridging peephole for "as" casts

Very good description. It's always worth re-explaining terms like bridged conversion to make sure every body is on the same page. But concerning the rules at the end, I’m not quite sure I understood them all. Please let me know if I’m correct: No bridging conversions will be performed if: -

Re: [swift-evolution] [SR-3281] Update swift man page

Looks great…at least, it’s much better than the old one. One thing that stuck out was the “by Apple Inc.” in the synopsis. I think you should ask one of the Core Team members for advice on this, but to me it 1. reduces the impact of outside collaborators on the language and 2. makes it appear t

[swift-evolution] [SR-3281] Update swift man page

Hi everyone, I have submitted an attempt at updating the swift man(1) page as Github Pull Request #10241 [1] based on the JIRA ticket SR-3281 [2]. Feedback is welcomed up to the end of Thursday, June 15th, preferably through discussion in the pull request thread and not through the mailing list.

Re: [swift-evolution] Introduction of OrderedSet

Sent from my iPhone > On Jun 13, 2017, at 6:05 AM, Maik Koslowski wrote: > > It’s definitely more effort needed than i thought at first. I can create an > API suggestion, but that will take a while. Since this will happen in Swift 5 > or later, we will have enough time anyway. Right. There

Re: [swift-evolution] Swift phases and mis-timed proposals

What if instead of a FIFO queue, we had a reddit style queue where proposals can bubble up based on community interest? It might help us figure out what to focus on in the 'phase 2' times where we allow a few out of scope proposals through... we just grab a couple off of the top. Thanks, Jon S

Re: [swift-evolution] [Review] SE-0180: String Index Overhaul

I’m coming to this conversation rather late, so forgive the naive question: Your proposal claims that current code with failable APIs is needlessly awkward and that most code only interchanges indices that are known to succeed. So, why is it not simply a precondition of string slicing that the ind

Re: [swift-evolution] Introducing synthesized locks

It's relatively unlikely that Swift's concurrency model, once it gains one, will look all that similar to Objective-C's. For example*, if Swift were to adopt a shared-nothing model where heap storage was per-thread and could only be accessed by another thread by copying or moving the value to it

Re: [swift-evolution] [Review] SE-0180: String Index Overhaul

on Tue Jun 06 2017, Dave Abrahams wrote: >> Overall it looks pretty good. But unfortunately the answer to "Will >> applications still compile but produce different behavior than they >> used to?" is actually "Yes", when using APIs provided by >> Foundation. This is because Foundation is currentl

Re: [swift-evolution] [Pitch] Introduction of `weak/unowned` closures

> On Jun 10, 2017, at 2:42 PM, Paul Cantrell via swift-evolution > wrote: > > Being able to specify things about closure capturing at the API level could > do wonders for Siesta — though its problems may be beyond the scope of what’s > proposed here (or what’s workable at all). > > Siesta ex

Re: [swift-evolution] Introducing synthesized locks

Synchronization would indeed be an area of improvement for Swift. I would, however, add that the primitive should also work with more than just functions. For example, it should play nicely with closures and should most definitely work with properties (to synchronize access for a given resource

Re: [swift-evolution] Swift phases and mis-timed proposals

> On Jun 12, 2017, at 7:16 PM, Jonathan Hull via swift-evolution > wrote: > >> On Jun 12, 2017, at 5:12 PM, Ted Kremenek via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >>> On Jun 12, 2017, at 12:47 PM, Paul Cantrell wrote: >>> >>> Concern #2 is that it’s hard to know wh

Re: [swift-evolution] [Review] SE-0180: String Index Overhaul

on Mon Jun 12 2017, David Waite wrote: >> On Jun 9, 2017, at 9:24 PM, Dave Abrahams via swift-evolution > wrote: >> on Fri Jun 09 2017, Kevin Ballard >> > > >> wrote: >>> On Tue, Jun 6, 2017, at 10:57 AM, Dave Abrahams via swift-evolution wrote: > >>> >>> Ah,

Re: [swift-evolution] Swift phases and mis-timed proposals

> On Jun 13, 2017, at 11:46 AM, Erica Sadun via swift-evolution > wrote: > > I imagine that recent discussions like mapped keypaths, ordered sets, > `count(where:)`, etc. could have a home for discussion and exploration > without getting blocked by "out of scope" if there were a separate > "

Re: [swift-evolution] [Proposal] Change Void meaning

> On Jun 13, 2017, at 2:02 PM, Beta wrote: > They may be semantically distinct and part of the type system, but they are > not types. Yes. That is already true, though. Our internal representation is unfortunate but it largely doesn't actually affect the language, just the complexity of the

Re: [swift-evolution] Swift phases and mis-timed proposals

> On Jun 13, 2017, at 2:07 AM, Xiaodi Wu via swift-evolution > wrote: > > On Tue, Jun 13, 2017 at 1:18 AM, Chris Lattner via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > >> On Jun 12, 2017, at 10:07 PM, Paul Cantrell via swift-evolution >> mailto:swift-evolution@swift.org>>

Re: [swift-evolution] [Proposal] Change Void meaning

They may be semantically distinct and part of the type system, but they are not types. I don’t think they should be given the privilege of overloading, but this is a separate discussion. ~Robert Widmann > On Jun 13, 2017, at 11:00 AM, John McCall wrote: > >> On Jun 13, 2017, at 1:48 PM, Beta

Re: [swift-evolution] [Proposal] Change Void meaning

> On Jun 13, 2017, at 1:48 PM, Beta wrote: > I would like to note that overloading on inout is a code smell and something > that should be removed in a future version of the language. inout is not a > type, it’s a SIL type residency annotation. Uh, no, inout arguments are semantically extremel

Re: [swift-evolution] [Proposal] Change Void meaning

I would like to note that overloading on inout is a code smell and something that should be removed in a future version of the language. inout is not a type, it’s a SIL type residency annotation. ~Robert Widmann > On Jun 13, 2017, at 10:40 AM, Xiaodi Wu via swift-evolution > wrote: > > Note

Re: [swift-evolution] [Proposal] Change Void meaning

But yes, I agree with the overall point that (while a very interesting idea (IMO)) there are definitely a _lot_ of cases to consider before it’s clearly viable as a solution. On Tue, Jun 13, 2017 at 12:43 Jens Persson wrote: > Ah, right! > > On Tue, Jun 13, 2017 at 7:40 PM, Xiaodi Wu wrote: > >>

Re: [swift-evolution] [Proposal] Change Void meaning

Ah, right! On Tue, Jun 13, 2017 at 7:40 PM, Xiaodi Wu wrote: > Note that “inout Void” is a distinct type from “Void”; it is not possible > to specify a default value for an inout Void parameter even explicitly > (“error: cannot pass immutable value of type ()...”), so naturally it > cannot be do

Re: [swift-evolution] [Proposal] Change Void meaning

Note that “inout Void” is a distinct type from “Void”; it is not possible to specify a default value for an inout Void parameter even explicitly (“error: cannot pass immutable value of type ()...”), so naturally it cannot be done implicitly either. On Tue, Jun 13, 2017 at 12:29 Jens Persson wrote:

Re: [swift-evolution] [Proposal] Change Void meaning

The std lib swap could perhaps be an interesting example to consider: public func swap(_ a: inout T, _ b: inout T) What would happen with that? Will inout arguments be an exception to the rule of Void getting a default value, and if so, what would the effects of that be? Or would it somehow be all

Re: [swift-evolution] Introducing synthesized locks

I'd prefer to see block-scoped synchronization rather than whole-method-only; it gives much more flexibility. Note that you can use the objc synchronization feature with reference types: // Or (_ obj:...) if you prefer the label-less objc style) func synchronized(on obj: AnyObject, do block: ()

Re: [swift-evolution] [Proposal] Change Void meaning

> On Jun 13, 2017, at 4:41 AM, Xiaodi Wu wrote: > > On Tue, Jun 13, 2017 at 3:06 AM, John McCall > wrote: >> On Jun 13, 2017, at 3:30 AM, Jérémie Girault > > wrote: >> >> Exactly, >> The reflexion behind it is: >> >> - Let's under

Re: [swift-evolution] Introducing synthesized locks

With a serial queue guarding the function or concurrent queues dumping into a serial target queue, DispatchQueue.sync(execute:) can be used as a synchronizing primitive suitable for most workflows. Have you tried exploring libDispatch outside of Semaphores? ~Robert Widmann > On Jun 12, 2017,

Re: [swift-evolution] [Proposal] Change Void meaning

On Tue, Jun 13, 2017 at 04:06 Florent Bruneau wrote: > > > Le 13 juin 2017 à 10:41, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> a écrit : > > > >> On Tue, Jun 13, 2017 at 3:06 AM, John McCall > wrote: > >>> On Jun 13, 2017, at 3:30 AM, Jérémie Girault < > jeremie.gira...@gmail.c

Re: [swift-evolution] Introduction of OrderedSet

It’s definitely more effort needed than i thought at first. I can create an API suggestion, but that will take a while. Since this will happen in Swift 5 or later, we will have enough time anyway. Does it make sense to create a proposal on GitHub or should I wait at least for Swift 5 since this

Re: [swift-evolution] [Proposal] Change Void meaning

I think Xiaodi’s “problem” is that he’s so knowledgeable of everything that’s happened on this list that when he sees efforts move in what he – usually correctly, I think – perceives to be an unproductive direction he points it out instead of letting the list spin its wheels or rehash old ideas

Re: [swift-evolution] [Proposal] Change Void meaning

— very short reply expected - vsre.info Jérémie Girault On 13 juin 2017 at 10:41:52, Xiaodi Wu (xiaodi...@gmail.com) wrote: On Tue, Jun 13, 2017 at 3:06 AM, John McCall wrote: > On Jun 13, 2017, at 3:30 AM, Jérémie Girault > wrote: > > Exactly, > The reflexion behind it is: > > - Let's underst

Re: [swift-evolution] [Proposal] Change Void meaning

On 13.06.2017 3:35, John McCall wrote: On Jun 12, 2017, at 6:42 PM, Vladimir.S wrote: John, could you clarify the details regarding function types, SE-0066 and SE-0110 implementations *planned* for Swift 4 release? I believe all these are important questions to be answered to understand the

Re: [swift-evolution] [Proposal] Change Void meaning

For clarity and improvement, could you please post a sample where an ambiguity could happen? I can't think of the issue here. I think that type-safety can still be conserved. — very short reply expected - vsre.info Jérémie Girault On 13 juin 2017 at 11:06:54, Florent Bruneau via swift-evolution (

Re: [swift-evolution] [Proposal] Change Void meaning

On 13.06.2017 9:42, David Sweeris via swift-evolution wrote: On Jun 12, 2017, at 10:45 PM, Gwendal Roué via swift-evolution wrote: "Discussing" with Xiaodi is a special experience, isn't it? He will bite and misrepresent you and your ideas until you get tired and your idea has been exhaust

Re: [swift-evolution] [Proposal] Change Void meaning

> Le 13 juin 2017 à 10:41, Xiaodi Wu via swift-evolution > a écrit : > >> On Tue, Jun 13, 2017 at 3:06 AM, John McCall wrote: >>> On Jun 13, 2017, at 3:30 AM, Jérémie Girault >>> wrote: >>> >>> Exactly, >>> The reflexion behind it is: >>> >>> - Let's understand that 0110 and other tuple

Re: [swift-evolution] [Proposal] Change Void meaning

On Tue, Jun 13, 2017 at 3:06 AM, John McCall wrote: > On Jun 13, 2017, at 3:30 AM, Jérémie Girault > wrote: > > Exactly, > The reflexion behind it is: > > - Let's understand that 0110 and other tuple SE are important for the > compiler, we do not want them to rollback > - However we have number

Re: [swift-evolution] Swift phases and mis-timed proposals

On Tue, Jun 13, 2017 at 1:18 AM, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote: > > On Jun 12, 2017, at 10:07 PM, Paul Cantrell via swift-evolution < > swift-evolution@swift.org> wrote: > > > Perhaps the solution is not necessarily throttling proposals per se, but > having s

Re: [swift-evolution] [Proposal] Change Void meaning

> On Jun 13, 2017, at 3:30 AM, Jérémie Girault > wrote: > > Exactly, > The reflexion behind it is: > > - Let's understand that 0110 and other tuple SE are important for the > compiler, we do not want them to rollback > - However we have number of regressions for generics / functional program

Re: [swift-evolution] Swift phases and mis-timed proposals

> On Jun 13, 2017, at 12:34 AM, John McCall wrote: > >> On Jun 13, 2017, at 3:22 AM, David Sweeris > > wrote: >>> On Jun 13, 2017, at 12:18 AM, John McCall via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> On Jun 13, 2017, at 1:08 AM, Jacob

Re: [swift-evolution] Swift phases and mis-timed proposals

> On Jun 13, 2017, at 3:22 AM, David Sweeris wrote: >> On Jun 13, 2017, at 12:18 AM, John McCall via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >>> On Jun 13, 2017, at 1:08 AM, Jacob Bandes-Storch via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> On Mon,

Re: [swift-evolution] [Proposal] Change Void meaning

Exactly, The reflexion behind it is: - Let's understand that 0110 and other tuple SE are important for the compiler, we do not want them to rollback - However we have number of regressions for generics / functional programmers - Let’s solve this step by step like a typical problem - Step 0 is adr

Re: [swift-evolution] [Proposal] Change Void meaning

> On Jun 13, 2017, at 1:45 AM, Gwendal Roué via swift-evolution > wrote: > > "Discussing" with Xiaodi is a special experience, isn't it? > > He will bite and misrepresent you and your ideas until you get tired and your > idea has been exhausted to death and diluted in dozens of useless messag

Re: [swift-evolution] Swift phases and mis-timed proposals

> On Jun 13, 2017, at 12:18 AM, John McCall via swift-evolution > wrote: > >> On Jun 13, 2017, at 1:08 AM, Jacob Bandes-Storch via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> On Mon, Jun 12, 2017 at 9:31 PM, Paul Cantrell via swift-evolution >> mailto:swift-evolution@swift

Re: [swift-evolution] Swift phases and mis-timed proposals

> On Jun 13, 2017, at 1:08 AM, Jacob Bandes-Storch via swift-evolution > wrote: > On Mon, Jun 12, 2017 at 9:31 PM, Paul Cantrell via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > I support everything Jon wrote. > > +1 Free-for-all brainstorming venue separate from focused propos