Re: [swift-evolution] Revisiting SE-0110

> On Jun 16, 2017, at 2:09 PM, Paul Cantrell wrote: > >> >> On Jun 16, 2017, at 3:43 PM, Mark Lacey > > wrote: >> >> >>> On Jun 16, 2017, at 1:21 PM, Mark Lacey >> >

Re: [swift-evolution] Revisiting SE-0110

> On Jun 16, 2017, at 1:21 PM, Mark Lacey wrote: > >> >> On Jun 16, 2017, at 11:13 AM, Paul Cantrell via swift-evolution >> > wrote: >> >>> >>> On Jun 15, 2017, at 7:17 PM, Xiaodi Wu via swift-evolution >>>

Re: [swift-evolution] Revisiting SE-0110

> On Jun 16, 2017, at 11:13 AM, Paul Cantrell via swift-evolution > wrote: > >> >> On Jun 15, 2017, at 7:17 PM, Xiaodi Wu via swift-evolution >> > wrote: >> >> >> On Thu, Jun 15, 2017 at 19:03 Víctor

Re: [swift-evolution] Revisiting SE-0110

> On Jun 15, 2017, at 8:23 AM, Robert Bennett via swift-evolution > wrote: > >> One (tangential) thing that came up is that tuple element names in tuple >> *patterns* should probably be deprecated and removed at some point. Without >> looking, what variables does

Re: [swift-evolution] Proposal: Always flatten the single element tuple

> On Jun 9, 2017, at 12:55 AM, Gwendal Roué wrote: > >> >> Le 9 juin 2017 à 09:41, Mark Lacey > > a écrit : >> >> >>> On Jun 9, 2017, at 12:12 AM, Gwendal Roué >>

Re: [swift-evolution] Proposal: Always flatten the single element tuple

> On Jun 9, 2017, at 12:12 AM, Gwendal Roué wrote: > >>> func notOverloaded1(_ closure: (Int, Int) -> Int) -> String { return >>> "notOverloaded1" } >>> func notOverloaded2(_ closure: ((lhs: Int, rhs: Int)) -> Int) -> String >>> { return "notOverloaded3" } >>>

Re: [swift-evolution] Proposal: Always flatten the single element tuple

> On Jun 8, 2017, at 11:37 PM, Gwendal Roué via swift-evolution > wrote: > > >> Le 9 juin 2017 à 07:56, Vladimir.S via swift-evolution >> > a écrit : >> >> Yes, we are discussing the *potential*

Re: [swift-evolution] Proposal: Always flatten the single element tuple

> On Jun 8, 2017, at 2:05 PM, Vladimir.S via swift-evolution > wrote: > > On 08.06.2017 21:17, Gwendal Roué via swift-evolution wrote: >>> Le 8 juin 2017 à 19:40, Brent Royal-Gordon via swift-evolution >>>

Re: [swift-evolution] Revisiting SE-0110

> On Jun 6, 2017, at 1:59 PM, Stephen Celis <stephen.ce...@gmail.com> wrote: > >> On Jun 6, 2017, at 1:43 PM, Mark Lacey via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> Unless I am missing something this is an example of tuple d

Re: [swift-evolution] Why is the status of SE-0110 "implemented"?

129> > Don't treat func signatures as being the same when they are in fact different > > https://bugs.swift.org/browse/SR-5130 <https://bugs.swift.org/browse/SR-5130> > Single-tuple and multiple-argument function types should be treated as > different types Thanks! Mark > >

Re: [swift-evolution] Revisiting SE-0110

uot;") > ) > """) > > It would be great if this functionality could be preserved somehow. ((double > brackets)) perhaps > but it would help library maintainers if this could also be back ported into > Swift 3.2. Unless I am missing somethin

Re: [swift-evolution] Revisiting SE-0110

> On Jun 6, 2017, at 8:42 AM, Ray Fix via swift-evolution > wrote: > > > FWIW, after doing a project migration last night and this morning, I am > reluctantly +1 for reverting SE-0110 and seeing a new proposal that can be > properly evaluated. The

Re: [swift-evolution] Why is the status of SE-0110 "implemented"?

uot;closureTuple is (Int,Int)->()") } > // result: closureTuple is (Int,Int)->() Can you open two reports at bugs.swift.org <http://bugs.swift.org/>, one for the ‘is’ issue, and one for type(of:)? These (along with the issue with function declarations that Jens mentioned) a

Re: [swift-evolution] Why is the status of SE-0110 "implemented"?

> On Jun 6, 2017, at 12:08 AM, Jens Persson via swift-evolution > wrote: > > IMHO There seems to be a lot of bugs and inconsistencies left in more than > just the reflective type system, for example the following won't compile > although the two foo funcs clearly

Re: [swift-evolution] Revisiting SE-0110

> On May 25, 2017, at 11:27 AM, John McCall via swift-evolution > wrote: > >> On May 25, 2017, at 2:23 PM, Nevin Brackett-Rozinsky via swift-evolution >> wrote: >> One possibility is to make parentheses consistently meaningful in closure

Re: [swift-evolution] [Pitch] inout with capture variable

> On Oct 5, 2016, at 10:07 PM, Cao Jiannan wrote: > > so if developer want to capture an variable inference, must declare a new > variable. I don’t follow what you mean here. > > class A { > var value = 1 > > func test() -> () -> Int { > var

Re: [swift-evolution] [Pitch] inout with capture variable

> On Oct 5, 2016, at 9:06 PM, Cao Jiannan via swift-evolution > wrote: > > for example: > > var a = 1 > > let block = { [inout a] in > a += 1 > } > > block() > block() > > print(a) // 3 This is already how captures work by default in closures and nested

Re: [swift-evolution] [Proposal draft] Disallow Optionals in String Interpolation Segments

> On Oct 4, 2016, at 10:29 AM, Kevin Ballard via swift-evolution > wrote: > > On Tue, Oct 4, 2016, at 10:28 AM, Nate Cook wrote: >>> On Oct 3, 2016, at 5:49 PM, Kevin Ballard via swift-evolution >>> >

Re: [swift-evolution] [Proposal draft] Disallow Optionals in String Interpolation Segments

PR later > today. > > - Harlan > > On Oct 3, 2016, at 4:06 PM, Mark Lacey via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > >> >>> On Oct 3, 2016, at 11:26 AM, Joe Groff via swift-evolution >&g

Re: [swift-evolution] [Proposal draft] Disallow Optionals in String Interpolation Segments

> On Oct 3, 2016, at 11:26 AM, Joe Groff via swift-evolution > wrote: > > >> On Oct 3, 2016, at 11:02 AM, Robert Widmann > > wrote: >> >> Because the initializer here doesn’t take Any, it takes . > > I

Re: [swift-evolution] pattern matching on variable-sized data type

> On Sep 6, 2016, at 7:47 AM, Jean-Denis Muys via swift-evolution > wrote: > > Hello, > > I would like to suggest an additive evolution to Swift that might be in scope > of phase 1 of Swift 4 (because it might have an impact on the ABI). How would you expect this

Re: [swift-evolution] [Swift4][Pitch] Control struct layout with @layout, @offset, @order

> On Aug 17, 2016, at 11:28 AM, Russ Bishop via swift-evolution > wrote: > > I wanted to gauge the interest in supporting explicit struct layout and > alignment. > > The general idea would be to support attributes to create packed structs and > set alignment. It

Re: [swift-evolution] [Meta] What does the backlog mean to the process?

> On Jul 29, 2016, at 09:30, Karl via swift-evolution > wrote: > > >> On 29 Jul 2016, at 18:01, Brandon Knope via swift-evolution >> wrote: >> >> I think this just shows how familiar many of us are with this process. >> >> It’s fun

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

> On Jul 21, 2016, at 10:37 PM, Dmitri Gribenko via swift-evolution > wrote: > > On Thu, Jul 21, 2016 at 10:17 PM, Xiaodi Wu wrote: >> Robert, the gist is notably vague on this point, so I'm hoping you will >> clarify. Are you proposing that

Re: [swift-evolution] [Meta] Proposal status page

> On Jul 18, 2016, at 4:44 PM, Jacob Bandes-Storch via swift-evolution > wrote: > > This is now live: http://apple.github.io/swift-evolution/ > Very very nice! I wonder if we should do something to avoid the 404 here

Re: [swift-evolution] Optional comparison operators

onal. I want to take another quick look at some of the changes I had to make to projects I looked at before I do so. Mark > > >> On Jul 12, 2016, at 9:09 AM, Mark Lacey via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>

Re: [swift-evolution] Optional comparison operators

> On Jul 12, 2016, at 12:16 AM, Jacob Bandes-Storch wrote: > > Okay, I guess it's fair that (T, T?) and (T?, T) overloads should have to be > a separate proposal. > > My personal motivation is mostly anecdotal; I've found them quite useful, and > I wouldn't say they're

Re: [swift-evolution] Optional comparison operators

> On Jul 11, 2016, at 11:55 PM, Jacob Bandes-Storch wrote: > > Mark, > Thanks for writing this up. Just to clarify, will these still work if your > proposal is implemented? > > let x: Int? > let y: Int > struct NotEquatable {} > let z: NotEquatable? > >

Re: [swift-evolution] Optional comparison operators

> On Jul 11, 2016, at 9:54 PM, Chris Lattner wrote: > >> >> On Jul 11, 2016, at 9:35 PM, Mark Lacey > > wrote: >> >> >>> On Jul 11, 2016, at 9:12 PM, Chris Lattner via swift-evolution >>>

Re: [swift-evolution] Optional comparison operators

> On Jul 11, 2016, at 9:12 PM, Chris Lattner via swift-evolution > wrote: > > >> On Jul 11, 2016, at 8:14 PM, Jacob Bandes-Storch via swift-evolution >> > wrote: >> >> You'd have to unwrap it, or use the

Re: [swift-evolution] Optional comparison operators

> On Jul 11, 2016, at 6:02 PM, Jacob Bandes-Storch wrote: > > On Mon, Jul 11, 2016 at 5:58 PM, Chris Lattner > wrote: > On Jul 11, 2016, at 4:56 PM, Jacob Bandes-Storch via swift-evolution >

Re: [swift-evolution] Optional comparison operators

> On Jul 11, 2016, at 4:59 PM, Xiaodi Wu wrote: > > Yup, I too would prefer removing the functions over removing coercion. Hi Xiaodi, Is there a reason you think the coercion is important to keep? I see these as somewhat orthogonal issues (allowing or disallowing

Re: [swift-evolution] Optional comparison operators

> On Jul 11, 2016, at 4:32 PM, Jacob Bandes-Storch wrote: > > Great, thanks Mark! I look forward to it. To be clear, I’m specifically looking at making the change to remove the coercion from T to T? for operator arguments. I agree there might be other things worth looking

Re: [swift-evolution] Optional comparison operators

Hi Jacob, > On Jul 11, 2016, at 4:23 PM, Jacob Bandes-Storch via swift-evolution > wrote: > > Bump for Swift 3. > > On Thu, Jul 7, 2016 at 2:37 PM, Jacob Bandes-Storch > wrote: > These operators cause some potential

Re: [swift-evolution] [Accepted] SE-0111: Remove type system significance of function argument labels

> On Jul 10, 2016, at 10:53 PM, Austin Zheng via swift-evolution > wrote: > > >> On Jul 10, 2016, at 10:30 PM, David Owens II > > wrote: I wish the core team or the author of the proposal came to this thread and

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

> On Jul 9, 2016, at 10:47 AM, David Sweeris via swift-evolution > wrote: > > > > Sent from my iPhone >> On Jul 9, 2016, at 11:29, Matthew Johnson via swift-evolution >> wrote: >> >>> On Jul 9, 2016, at 11:04 AM, Tino Heth

Re: [swift-evolution] [Proposal] Sealed classes by default

> On Jun 29, 2016, at 3:45 PM, Rod Brown via swift-evolution > wrote: > > From my understanding, "Sealed" or whatever we will call it technically > provides no actual optimisations. We cannot assume the class is final because > something inside the module may have

Re: [swift-evolution] [Proposal] Sealed classes by default

> On Jun 28, 2016, at 4:01 PM, Michael Peternell via swift-evolution > wrote: > > >> Am 29.06.2016 um 00:32 schrieb John McCall : >> >> The decision to make class methods polymorphic by default was always >> premised on being able to undo that

Re: [swift-evolution] [Proposal] Sealed classes by default

> On Jun 28, 2016, at 7:55 AM, Sean Heber <s...@fifthace.com> wrote: > >> On Jun 28, 2016, at 9:52 AM, Mark Lacey via swift-evolution >> <swift-evolution@swift.org> wrote: >> >>> >>> On Jun 27, 2016, at 9:10 PM, L. Mihalkovic via

Re: [swift-evolution] [Proposal] Sealed classes by default

> On Jun 27, 2016, at 9:10 PM, L. Mihalkovic via swift-evolution > wrote: > > -1 for the fact that if all devs can write working code, fewer can do it in a > clear structured fashion that is well designed for extensibility. This sounds more like an argument for

Re: [swift-evolution] [Pitch] "unavailable" members shouldn't need an impl

> On Jun 10, 2016, at 2:32 PM, Leonardo Pessoa via swift-evolution > wrote: > > I've seen around the Swift source code some uses of a function named > something like NSUnimplemented(). I'm not sure this is available only > inside the Swift source or if we could call

Re: [swift-evolution] [Pitch] Allow explicit specialization of generic functions

> On May 25, 2016, at 11:37 PM, David Hart wrote: > > The former. This proposal is simply to make certain scenarios which require > to be explicit to be more elegant and more in line with generic types. > > Moreover, what you suggest might be dangerous. Imagine this code: >

Re: [swift-evolution] [Pitch] Allow explicit specialization of generic functions

> On May 25, 2016, at 4:17 PM, David Hart via swift-evolution > wrote: > > Hello, > > This is a new pitch to allow explicitly specializing generic functions. > Notice that potential ambiguity with initialisers and how I’m currently > trying to avoid it. Please let

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0045: Add scan, prefix(while:), drop(while:), and iterate to the stdlib

I haven’t read through the complete proposal in detail, but regarding the ‘scan’ operation I would like to point out that the definition given in the example matches the semantics of what is usually called ‘prescan' or 'exclusive scan', whereas ‘scan’ (aka ‘inclusive scan’ or ‘prefix sum’)