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 >> > wrote: >>> On Jun 16, 2017, at 11:13 AM, Paul Cantrell vi

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 >> mailto:swift-evolution@swift.org>> wrote: >> >>> >>> On Jun 15, 2017, at 7:17 PM, Xiaodi Wu via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >>>

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 >> mailto:swift-evolution@swift.org>> wrote: >> >> >> On Thu, Jun 15, 2017 at 19:03 Víctor Pimentel > > wrote: >> On 16

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 this declare?: >> >> let (

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é >> > wrote: >>> > func notOverloaded1(_ closure: (Int, Int) -> I

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" } >>> >>> func overloa

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 >> mailto:swift-evolution@swift.org>> a écrit : >> >> Yes, we are discussing the *potential* solutions for Swift 4 that can >> decrease the pain of migratio

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 >>> mailto:swift-evolution@swift.org> >>>

Re: [swift-evolution] Revisiting SE-0110

> On Jun 6, 2017, at 1:59 PM, Stephen Celis wrote: > >> On Jun 6, 2017, at 1:43 PM, Mark Lacey via swift-evolution >> wrote: >> >> Unless I am missing something this is an example of tuple destructuring. I’m >> looking for examples of other issues. >

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

t 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 > > /Jens >

Re: [swift-evolution] Revisiting SE-0110

> On Jun 6, 2017, at 11:45 AM, Vladimir.S wrote: > > On 06.06.2017 20:10, Mark Lacey via swift-evolution wrote: >>> On Jun 6, 2017, at 8:42 AM, Ray Fix via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >>> >>&g

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

(_: >>> (Int,Int))->()") } >>> // result: closureParam is (_: (Int,Int))->() >>> >>> if closureTuple is (Int,Int)->() { print("closureTuple is (Int,Int)->()") } >>> // result: closureTuple is (Int,Int)->() &

Re: [swift-evolution] Revisiting SE-0110

; """) > > 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 something this is an example of

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 split-the-difference compromise mentioned s

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

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) are all similar issues, but

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 take different types as argum

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 >> argument lists, so that “(a, b)” would exclusively

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 capturedValue = self.value >

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 functions in Swift: var a =

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 >>> mailto:swift-evolution@swift.org>> wrote: >>> >>> On Mon, Oct 3, 2016, at 03:18 PM, Jordan Ros

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

gt; - Harlan > > On Oct 3, 2016, at 4:06 PM, Mark Lacey via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > >> >>> On Oct 3, 2016, at 11:26 AM, Joe Groff via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>

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 think there's a case to be made to generalize the 'Any' w

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 to have an impact on ABI? M

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 will be critical for certain

Re: [swift-evolution] Swift 3.1 discussions, go?

> On Aug 2, 2016, at 07:38, Xiaodi Wu via swift-evolution > wrote: > > I'd like to echo Muse's point. Accelerate is no solution: it's not available > on Linux (and cross-platform numerics is very much essential for the > sciences--I assume engineering and finance as well); moreover, it doesn'

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 and challenging coming up with the great ideas…but someon

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 FloatingPoint will break with IEEE754 >> semantics?

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 though: http://apple.github.io <

Re: [swift-evolution] Optional comparison operators

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 >> mailto:swift-evolution@swift.org>> wrote: >> >> >>> On Jul 11, 2016, at 11:55 P

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 uncommon. Sure, I mean

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? > > x == y; x != y >

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 >>> mailto:swift-evolution@swift.org>> wrote: >>> >>> On Jul 11, 2016, a

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 >> mailto:swift-evolution@swift.org>> wrote: >> >> You'd have to unwrap it, or use the ??/==/!= operators: >> https://gist.github.com/jtbande

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 > mailto:swift-evolution@swift.org>> wrote: > > Personally I think we should j

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 coercion vs. keeping or remo

Re: [swift-evolution] Optional comparison operators

> On Jul 11, 2016, at 4:56 PM, Jacob Bandes-Storch wrote: > > Personally I think we should just remove these optional-taking variants of > the comparison operators. Does anyone agree/disagree? I believe that a well-defined ordering of optionals and non-optionals is required in order to allow

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 at regarding operato

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 for confusion: > > public func <(lhs: T?, rhs

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 engaged again with the community. >>> >

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 <2...@gmx.de> wrote: >>> >>> Second: >>> Do you really believe the

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 vended a subclass. It can e

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 in obvious cases where methods are never >> ove

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

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

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 having sealed classes than not.

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 it as well (I'm not in > fro

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: > > func foo() -> (T

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 me know what you think! Hi

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’) would