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

> On Jun 29, 2016, at 10:27 PM, L. Mihalkovic > wrote: > > On Jun 29, 2016, at 9:54 PM, John McCall via swift-evolution > wrote: > >>> On Jun 29, 2016, at 12:05 PM, Michael Peternell >>> wrote: >>> I'm still unhappy about this "sealed by default" proposal. That really >>> looks like premat

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

> On Jun 29, 2016, at 10:17 PM, L. Mihalkovic > wrote: >> On Jun 29, 2016, at 8:39 PM, Vladimir.S via swift-evolution >> wrote: >> >> How about `public(extensible)` ? >> >> On 29.06.2016 21:32, John McCall via swift-evolution wrote: On Jun 29, 2016, at 11:16 AM, Michael Peternell via swi

Re: [swift-evolution] [Proposal draft] NSError bridging

> Note that, unlike with NSError, the provided errorUserInfo requires String > keys. Is there any way this could be tightened further to require Error.UserInfoKey keys (where Error.UserInfoKey is a Notification.Name-style wrapper)? -- Brent Royal-Gordon Architechies __

Re: [swift-evolution] [Review] SE-0077 v2: Improved operator declarations

https://github.com/apple/swift-evolution/blob/master/proposals /0077-operator-precedence.md Idea #1 There is a high chance that 'higherThan'/'lowerThan' names will be chosen. I still see a problem with that. Keywords in Swift are written in full lowercase, so we should actually take 'higherthan

Re: [swift-evolution] [Post Swift 3] [Proposal] Introducing `group` mechanism

> On 29 Jun 2016, at 22:41, David Sweeris via swift-evolution > wrote: > > Speaking of C++, is the “group” keyword even necessary? To borrow your own > example from earlier, it seems like we could just as easily say this: > public struct A { > public { // all public > func member1(

Re: [swift-evolution] [Post Swift 3] [Proposal] Introducing `group` mechanism

> On 30 Jun 2016, at 11:04, Haravikk via swift-evolution > wrote: > > This form is interesting, but personally when it comes to grouping I've > become a huge fan of using focused extensions, meaning my type declarations > are usually nothing but the bare minimum definition for stored properti

[swift-evolution] Re : [Post Swift 3] [Proposal] Introducing `group` mechanism

-- Adrian Zubarev Sent with Airmail Am 30. Juni 2016 um 12:13:10, Adrian Zubarev (adrian.zuba...@devandartist.com(mailto:adrian.zuba...@devandartist.com)) schrieb: > > We *could* remove the group keyword, but there is a problem with that. It > becomes really strange when you'll try nes

Re: [swift-evolution] Extend FloatingPoint with tau!

+1 Lots of win for very small effort. > Hello community, > > Tau day > was yesterday, and reminded > me that we forgot to provide a `tau` next to `FloatingPoint`’s `pi` property. > How about we write a proposal to brind this forward-thinking constant to a

Re: [swift-evolution] [Discussion] A Problem With SE-0025?

Sent from my iPad > On Jun 30, 2016, at 1:26 AM, Jean-Daniel Dupas wrote: > > >> Le 30 juin 2016 à 01:10, Matthew Johnson via swift-evolution >> a écrit : >> >> >>> On Jun 29, 2016, at 6:07 PM, David Hart via swift-evolution >>> wrote: >>> >>> On 29 Jun 2016, at 22:15, Jordan Ros

Re: [swift-evolution] [Proposal draft] NSError bridging

Sent from my iPad > On Jun 30, 2016, at 12:56 AM, Douglas Gregor via swift-evolution > wrote: > > >> On Jun 29, 2016, at 10:05 AM, Dmitri Gribenko wrote: >> >> On Wed, Jun 29, 2016 at 4:13 AM, Charles Srstka >> wrote: >>> On Jun 29, 2016, at 2:50 AM, Dmitri Gribenko via swift-evolution >>

Re: [swift-evolution] [Review] SE-0077 v2: Improved operator declarations

Sent from my iPad > On Jun 30, 2016, at 4:34 AM, Anton Zhilin via swift-evolution > wrote: > > https://github.com/apple/swift-evolution/blob/master/proposals > /0077-operator-precedence.md > > Idea #1 > > There is a high chance that 'higherThan'/'lowerThan' names will be > chosen. What is

Re: [swift-evolution] Extend FloatingPoint with tau!

> Lots of win for very small effort. > "Lots" like in not having to type "2 *"? -1 from me. Best regards, Rimantas ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Post Swift 3] [Proposal] Introducing `group` mechanism

Sent from my iPad > On Jun 30, 2016, at 5:10 AM, Haravikk via swift-evolution > wrote: > > >> On 30 Jun 2016, at 11:04, Haravikk via swift-evolution >> wrote: >> >> This form is interesting, but personally when it comes to grouping I've >> become a huge fan of using focused extensions, m

Re: [swift-evolution] [Pitch] Change custom operator rules to reserve operators for future use?

Sent from my iPad > On Jun 29, 2016, at 9:54 PM, Austin Zheng wrote: > > 90% of the list is bikeshedding over syntax right now. The idea that it might > be 'distracting' is wholly unconvincing to me, especially because the list > participants know exactly what bikeshedding is and eagerly eng

Re: [swift-evolution] [Pitch] Remove type inference for associated types

> On Jun 29, 2016, at 6:55 AM, Brandon Knope via swift-evolution > wrote: > > What's the rationale for having associatedtype in protocols and typealias in > the conforming types? I didn't design it, but here's how I think about it: The associated type requirement merely states that there must

Re: [swift-evolution] [Review] SE-0077 v2: Improved operator declarations

Matthew Johnson via swift-evolution writes: > > There is a high chance that 'higherThan'/'lowerThan' names will be > > chosen. > > What is giving you this idea? Did I miss some part of the conversation? I don't recall any indication of what > the final keywords will be. Yesterday Dave Abrah

Re: [swift-evolution] [Pitch] Change custom operator rules to reserve operators for future use?

I don’t like the idea (which I have seen in several different pitches recently) of breaking things now so that some theoretical future feature might be possible. Much better, I think, to wait until we have a concrete proposal and than break things then if necessary. Otherwise we will just leav

Re: [swift-evolution] Extend FloatingPoint with tau!

I would argue the reverse, i.e., removing pi as a property of FloatingPoint. What is it there vs. being part of a separate mathematic constants package? I don't see Euler's number or phi (golden ratio) in the proposal. Joe On Wed, Jun 29, 2016 at 2:45 AM, David Hart via swift-evolution < swift

Re: [swift-evolution] [Pitch] Remove type inference for associated types

But surely using two different keywords could seem confusing to many as part of the same system? Using associatedtype in the declaration and then typealias in the conforming type just seems inconsistent and ripe for confusion. ' I am curious if any advanced Swift users still get tripped up here

Re: [swift-evolution] [Post Swift 3] [Proposal] Introducing `group` mechanism

I also floated this idea awhile back too: http://article.gmane.org/gmane.comp.lang.swift.evolution/17289 Obviously this kind of thing is out of scope for Swift 3 Brandon Sent from my iPad > On Jun 30, 2016, at 8:14 AM, Matthew Johnson via swift-evolution > wrote: > > > > Sent from my iPa

Re: [swift-evolution] [Review] SE-0077 v2: Improved operator declarations

> On Jun 30, 2016, at 7:58 AM, Anton Zhilin via swift-evolution > wrote: > > Matthew Johnson via swift-evolution writes: > >>> There is a high chance that 'higherThan'/'lowerThan' names will be >>> chosen. >> >> What is giving you this idea? Did I miss some part of the > conversation? I

Re: [swift-evolution] Extend FloatingPoint with tau!

This was discussed as part of SE-0067. The consensus was that pi deserved special treatment, as it is used in general-purpose code an order of magnitude more often than the all other constants combined. I don’t think that anyone argued against it’s inclusion. – Steve > On Jun 30, 2016, at 9:1

Re: [swift-evolution] Extend FloatingPoint with tau!

-1 Tau, unlike pi, is not a commonly understood mathematical constant. Even in the realm of mathematics, tau is used to represent multiple concepts and other constants, such as the golden ratio. Finally, tau is easily computed from pi and should not result in a loss of precision. This makes

Re: [swift-evolution] [Pitch] Remove type inference for associated types

No, but I don't think I'd be opposed to this: struct MyCollection { associatedtype Index = struct _ : Comparable { … } // struct's name is implicitly also "Index" } - Dave Sweeris On Jun 30, 2016, at 07:53, Brent Royal-Gordon via swift-evolution wrote: >struct MyCollection { >

Re: [swift-evolution] [Proposal] Remove force unwrapping in function signature.

The only reason I can think of writing a function with a force-unwrapped parameter is overriding an API function with such a signature, as Chris mentioned. If the function actually doesn’t accept nil you might feel obliged to start the function with something like precondition( IUO argument !=

Re: [swift-evolution] Extend FloatingPoint with tau!

> On Jun 30, 2016, at 9:22 AM, Stephen Canon via swift-evolution > wrote: > > This was discussed as part of SE-0067. > > The consensus was that pi deserved special treatment, as it is used in > general-purpose code an order of magnitude more often than the all other > constants combined. I

Re: [swift-evolution] [Review] SE-0077 v2: Improved operator declarations

> On Jun 30, 2016, at 2:34 AM, Anton Zhilin via swift-evolution > wrote: > > https://github.com/apple/swift-evolution/blob/master/proposals > /0077-operator-precedence.md > > Idea #1 > > There is a high chance that 'higherThan'/'lowerThan' names will be > chosen. I still see a problem with t

Re: [swift-evolution] Notification.Name

[Cc: Michael Ilseman] > On 30 Jun 2016, at 03:13, Brent Royal-Gordon via swift-evolution > wrote: > > Not 100% sure this belongs here, but I'll bite. > > The new `Notification.Name` type is a beautiful application of SE-0033 > "Import Objective-C Constants as Swift Types"[1] which removes a l

Re: [swift-evolution] [Discussion] A Problem With SE-0025?

> On Jun 29, 2016, at 23:34, John McCall wrote: > >> On Jun 29, 2016, at 7:07 PM, Xiaodi Wu via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> [Resending with fewer recipients] >> >> On Wed, Jun 29, 2016 at 8:55 PM, Jordan Rose > > wrote: >> U

Re: [swift-evolution] [Proposal] Remove force unwrapping in function signature.

Now that I think of it, IUOs for function returns have a similar problem. When I see an IUO property, I consider it a sort of “contract”–it’s basically saying something like “I can’t set this to a valid value right now, but by the time you use it I promise that it’s non nil”. That’s why IUOs make s

Re: [swift-evolution] Notification.Name

> On Jun 30, 2016, at 9:10 AM, Ben Rimmington wrote: > > [Cc: Michael Ilseman] > >> On 30 Jun 2016, at 03:13, Brent Royal-Gordon via swift-evolution >> wrote: >> >> Not 100% sure this belongs here, but I'll bite. >> >> The new `Notification.Name` type is a beautiful application of SE-0033

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0107: UnsafeRawPointer API

>> * What is your evaluation of the proposal? This is an excellent proposal, and a step forward in balancing safety and un-safety in an understandable way. I have no issues about the substance, but two documentation issues: - the compiler’s strict aliasing rules: not clearly defined in this do

Re: [swift-evolution] [Discussion] A Problem With SE-0025?

Cool. FWIW, even in such a world, I wonder if the conformance needs to be regarded as `fileprivate`: In all cases where a private protocol is visible and conformance can be declared, the protocol's access level would be-- - effectively fileprivate (if both protocol and conformance are declared to

Re: [swift-evolution] Extend FloatingPoint with tau!

> On Jun 30, 2016, at 9:01 AM, David Waite via swift-evolution > wrote: > > >> On Jun 30, 2016, at 9:22 AM, Stephen Canon via swift-evolution >> wrote: >> >> This was discussed as part of SE-0067. >> >> The consensus was that pi deserved special treatment, as it is used in >> general-purp

[swift-evolution] [Rejected] SE-0105: Removing Where Clauses from For-In Loops

Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0105-remove-where-from-forin-loops.md Hello Swift Community, The review of "SE-0105: Removing Where Clauses from For-In Loops" ran from June 22...29, 2016. The proposal is *rejected* for Swift 3. The vast majority

Re: [swift-evolution] [Pitch] Remove type inference for associated types

I don't see that as confusing. In a conforming type, he compiler is looking for a type with the same name as the associatedtype declaration. As the proposal mentions, typealias is not the only way to provide that type. It's actually logical to typealias to point the compiler to the correct type

Re: [swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines

Agreed. Also, if we’re supposed to say `MemoryLayout.of()` now, does MemoryLayout still need a public init? Half of the proposal’s problems revolve around the likely-unexpected behavior caused by passing T.self to the init function (although, argument labels would also solve the issue). - Dave

Re: [swift-evolution] [Pitch] Remove destructive consumption from Sequence

on Wed Jun 29 2016, Haravikk wrote: >> On 29 Jun 2016, at 00:10, Matthew Johnson via swift-evolution >> wrote: >> >> Swift is a language that embraces value semantics. Many common >> iterators *can* be implemented with value semantics. Just because we >> can’t implement *all* iterators with

Re: [swift-evolution] [Discussion] A Problem With SE-0025?

> On Jun 30, 2016, at 9:19 AM, Jordan Rose wrote: >> On Jun 29, 2016, at 23:34, John McCall > > wrote: >> >>> On Jun 29, 2016, at 7:07 PM, Xiaodi Wu via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >>> [Resending with fewer recipients] >>> >>> On

Re: [swift-evolution] [Pitch] Remove type inference for associated types

> On Jun 30, 2016, at 9:55 AM, David Hart via swift-evolution > wrote: > > I don't see that as confusing. In a conforming type, he compiler is looking > for a type with the same name as the associatedtype declaration. As the > proposal mentions, typealias is not the only way to provide that t

Re: [swift-evolution] [Pitch] Remove type inference for associated types

> On Jun 30, 2016, at 10:28 AM, Douglas Gregor via swift-evolution > wrote: > >> >> On Jun 30, 2016, at 9:55 AM, David Hart via swift-evolution >> wrote: >> >> I don't see that as confusing. In a conforming type, he compiler is looking >> for a type with the same name as the associatedtype

Re: [swift-evolution] [Pitch] Remove destructive consumption from Sequence

If Iterators become reference types that model single-pass sequences and becomes for-in-able, as the write-up suggests, couldn't Sequence be stipulated to be multipass and retain its refinement relationship with Collection? On Thu, Jun 30, 2016 at 12:26 Dave Abrahams via swift-evolution < swift-ev

Re: [swift-evolution] [Pitch] Remove type inference for associated types

> On Jun 30, 2016, at 10:31 AM, Kevin Nattinger wrote: > > >> On Jun 30, 2016, at 10:28 AM, Douglas Gregor via swift-evolution >> wrote: >> >>> >>> On Jun 30, 2016, at 9:55 AM, David Hart via swift-evolution >>> wrote: >>> >>> I don't see that as confusing. In a conforming type, he compi

Re: [swift-evolution] [Proposal draft] NSError bridging

> On Jun 30, 2016, at 2:19 AM, Brent Royal-Gordon > wrote: > >> Note that, unlike with NSError, the provided errorUserInfo requires String >> keys. > > Is there any way this could be tightened further to require Error.UserInfoKey > keys (where Error.UserInfoKey is a Notification.Name-style w

Re: [swift-evolution] [Pitch] Remove destructive consumption from Sequence

> On Jun 30, 2016, at 10:26 AM, Dave Abrahams via swift-evolution > wrote: > > It would > be very interesting to know about any real-world models of single-pass > sequences that people are using in Swift, since we don't supply any in > the standard library. > > -- > Dave I already gave an e

Re: [swift-evolution] [Pitch] Remove type inference for associated types

I know :) I've been following the mailing list attentively since the beginning! I was just trying to give my rational for why I think it is still logical to have typealias for conforming to the associatedtype. > On 30 Jun 2016, at 19:28, Douglas Gregor wrote: > > >> On Jun 30, 2016, at 9:55 A

Re: [swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines

As a meta-issue, it's been hard to make meaningful commentary during this review process because the latest proposal has been so rapidly shifting throughout. What, exactly, is the version we are reviewing at the moment? Can we have a few days to mull over that version specifically? On Thu, Jun 30,

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

> On Jun 30, 2016, at 1:21 AM, John McCall via swift-evolution > wrote: > >> On Jun 29, 2016, at 10:17 PM, L. Mihalkovic >> wrote: >>> On Jun 29, 2016, at 8:39 PM, Vladimir.S via swift-evolution >>> wrote: >>> >>> How about `public(extensible)` ? >>> >>> On 29.06.2016 21:32, John McCall v

Re: [swift-evolution] [Review] SE-0077 v2: Improved operator declarations

> On Jun 30, 2016, at 2:34 AM, Anton Zhilin via swift-evolution > wrote: > https://github.com/apple/swift-evolution/blob/master/proposals > /0077-operator-precedence.md > > Idea #1 > > There is a high chance that 'higherThan'/'lowerThan' names will be > chosen. I still see a problem with that.

Re: [swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines

Good point; ideally, there would be no initializers at all. On Thu, Jun 30, 2016 at 10:24 AM, David Sweeris wrote: > Agreed. Also, if we’re supposed to say `MemoryLayout.of()` now, does > MemoryLayout still need a public init? Half of the proposal’s problems > revolve around the likely-unexpecte

Re: [swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines

The only proposal that's in review is the one on github at Swift Evolution. I have been putting together another version as a courtesy for Dave A, to flesh out how the alternative approach would look if the alternative was the primary proposal. That one is a personal gist. -- E > On Jun 30, 2

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

> On Jun 30, 2016, at 11:07 AM, Andrew Trick wrote: >> On Jun 30, 2016, at 1:21 AM, John McCall via swift-evolution >> wrote: >> >>> On Jun 29, 2016, at 10:17 PM, L. Mihalkovic >>> wrote: On Jun 29, 2016, at 8:39 PM, Vladimir.S via swift-evolution wrote: How about `publ

[swift-evolution] [Review] SE-0110: Distinguish between single-tuple and multiple-argument function types

Hello Swift community, The review of "SE-0110: Distinguish between single-tuple and multiple-argument function types" begins now and runs through July 4. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0110-distingish-single-tuple-arg.md

[swift-evolution] [Review] SE-0112: Improved NSError Bridging

Hello Swift community, The review of "SE-0112: Improved NSError Bridging" begins now and runs through July 4. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0112-nserror-bridging.md Reviews are an important part of the Swift evolution pro

Re: [swift-evolution] [Review] SE-0077 v2: Improved operator declarations

Sent from my iPad On Jun 30, 2016, at 1:08 PM, John McCall via swift-evolution wrote: >> On Jun 30, 2016, at 2:34 AM, Anton Zhilin via swift-evolution >> wrote: >> https://github.com/apple/swift-evolution/blob/master/proposals >> /0077-operator-precedence.md >> >> Idea #1 >> >> There is a

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

Hello Swift community, The review of "SE-0111: Remove type system significance of function argument labels" begins now and runs through July 4. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md Revi

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

Sent from my iPad On Jun 30, 2016, at 1:15 PM, John McCall via swift-evolution wrote: >>> On Jun 30, 2016, at 11:07 AM, Andrew Trick wrote: On Jun 30, 2016, at 1:21 AM, John McCall via swift-evolution wrote: > On Jun 29, 2016, at 10:17 PM, L. Mihalkovic > wrote: >

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

> On Jun 30, 2016, at 12:26 PM, Chris Lattner via swift-evolution > wrote: > > https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md > >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0112: Improved NSError Bridging

+1 I continually find the use of `as` for bridging between Objective-C and Swift types to be confusing, since they do not have a true place in the Swift type hierarchy and are not simple casts. The `catch let error as NSError` construct always implies that NSError is a true type that can be thr

Re: [swift-evolution] [Review] SE-0110: Distinguish between single-tuple and multiple-argument function types

> The review of "SE-0110: Distinguish between single-tuple and > multiple-argument function types" begins now and runs through July 4. The > proposal is available here: > > > https://github.com/apple/swift-evolution/blob/master/proposals/0110-distingish-single-tuple-arg.md > > * Wh

Re: [swift-evolution] [Review] SE-0110: Distinguish between single-tuple and multiple-argument function types

> * What is your evaluation of the proposal? Positive. I thought this was a bug, post SE-0029. > * Is the problem being addressed significant enough to warrant a change to > Swift? Yes. > * Does this proposal fit well with the feel and direction of Swift? Yes. > * If you have used other lang

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

This mostly makes sense to me and it seems like mostly a good idea, but take this example: func doSomething(x: Int, y: Int) -> Bool { return true } let x = doSomething x(10, 10) Is it then legal to do this?: x(blahblah:10, totallyOffTheWallLabelThatDoesNotAppearANYWHERE: 10) That would seem od

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0107: UnsafeRawPointer API

Thanks for reviewing! > On Jun 30, 2016, at 9:37 AM, Guillaume Lessard via swift-evolution > wrote: > > >>> * What is your evaluation of the proposal? > > This is an excellent proposal, and a step forward in balancing safety and > un-safety in an understandable way. > > I have no issues abo

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

-1 This proposal doesn’t even use Swift naming style to make its point, as soon as you do, the reason why Swift considers argument labels to be part of the type signature becomes apparent. The author of the proposal uses the following example: func doSomething(x: Int, y: Int) -> Bool This

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

This is a good point. I feel like calling `x` with any sort of argument labels should be prohibited. I don't think there's any expressivity penalty for doing so (especially since tuple splat is gone); plus, once a function is reified as a value (as opposed to being invoked by naming it directly), I

Re: [swift-evolution] [Review] SE-0077 v2: Improved operator declarations

> On Jun 30, 2016, at 11:25 AM, Matthew Johnson wrote: > On Jun 30, 2016, at 1:08 PM, John McCall via swift-evolution > wrote: > >>> On Jun 30, 2016, at 2:34 AM, Anton Zhilin via swift-evolution >>> wrote: >>> https://github.com/apple/swift-evolution/blob/master/proposals >>> /0077-operator-p

Re: [swift-evolution] Enhanced existential types proposal discussion

> On May 17, 2016, at 11:52 AM, Austin Zheng via swift-evolution > wrote: > > I put together the skeleton of a proposal detailing enhancements to how > associated types can be referenced in Swift 3+. It's certainly not ready for > submission, but I think it gets across my ideas pretty well. W

Re: [swift-evolution] [Review] SE-0077 v2: Improved operator declarations

As Anton mentioned earlier, I feel the same way with respect to naming. No need to reiterate the points already made, but I do want to chime in on the topic of rarely used syntax. While I agree of course that a cumbersome syntax for a rarely used feature is _not as bad_ as a cumbersome syntax for

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

On Thu, Jun 30, 2016 at 11:43 AM, Scott James Remnant via swift-evolution < swift-evolution@swift.org> wrote: > -1 > > This proposal doesn’t even use Swift naming style to make its point, as > soon as you do, the reason why Swift considers argument labels to be part > of the type signature becomes

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

Austin, I agree with your point here that any sort of label should be prohibited at the call site if your proposal is adopted; along those lines, your suggested alternative of disallowing them in the type annotation might win in terms of appropriately setting user expectations about labels despite

[swift-evolution] [Returned for Revision] SE-0101: Rename sizeof and related functions to comply with API Guidelines

Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0101-standardizing-sizeof-naming.md Hello Swift Community, The review of "SE-0101: Rename sizeof and related functions to comply with API Guidelines" ran from June 21...27, 2016. The proposal is *returned for revisio

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

> They already *are* type compatible. This works right now: > > var a : (ofHits: Int, forRuns: Int) -> Bool = meetsBattingAverage > a = sinkBattleship > // ??? > a(ofHits: 1, forRuns: 2) Your proposal does not make it clear that this works (which is surprising to me). I would argue the proposal

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

This should probably be a motivating example. I'll add an Alternative to keep the present behavior and tighten the requirements. Austin On Thu, Jun 30, 2016 at 11:56 AM, Scott James Remnant wrote: > > They already *are* type compatible. This works right now: > > > > var a : (ofHits: Int, forRu

Re: [swift-evolution] [Review] SE-0077 v2: Improved operator declarations

> On Jun 30, 2016, at 1:48 PM, Xiaodi Wu wrote: > > As Anton mentioned earlier, I feel the same way with respect to naming. No > need to reiterate the points already made, but I do want to chime in on the > topic of rarely used syntax. > > While I agree of course that a cumbersome syntax for

Re: [swift-evolution] Request for quickie proposal and review

on Tue Jun 28 2016, Erica Sadun wrote: > Dave: > > I think this should be changed: > > return withUnsafeMutablePointers { (v, e) in return body(v) } > > should be > > return withUnsafeMutablePointers { (h, e) in return body(h) } Looks good. > -- E > >> On Jun 28, 2016, at 8:04 PM, Dave Abraham

Re: [swift-evolution] Request for quickie proposal and review

on Tue Jun 28 2016, Erica Sadun wrote: > Please look through: > > https://gist.github.com/erica/af357a47ec5c1d26028769e1676af799 > > Let me know what corrections you want. Once you do so, I'll put it in > as a pull request. I think the only thing needed is a reference to the patch https://git

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

> On 30 Jun 2016, at 20:26, Chris Lattner via swift-evolution > wrote: > > Hello Swift community, > > The review of "SE-0111: Remove type system significance of function argument > labels" begins now and runs through July 4. The proposal is available here: > > > https://github.com/app

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

On Thu, Jun 30, 2016 at 2:14 PM, Taras Zakharko via swift-evolution < swift-evolution@swift.org> wrote: > > > On 30 Jun 2016, at 20:26, Chris Lattner via swift-evolution < > swift-evolution@swift.org> wrote: > > > > Hello Swift community, > > > > The review of "SE-0111: Remove type system signific

Re: [swift-evolution] [Review] SE-0110: Distinguish between single-tuple and multiple-argument function types

> > * What is your evaluation of the proposal? +1. This solves something that I find a bit annoying. > * Is the problem being addressed significant enough to warrant a change > to Swift? Yes > * Does this proposal fit well with the feel and direction of Swift? Yes >

Re: [swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines

on Wed Jun 29 2016, David Sweeris wrote: > (While I was typing this up, I realized that the exact usage you’re > worried about, “MemoryLayout(Int.self).size” won’t compile, since > `MemoryLayout` currently doesn’t have instance properties. If you’re > worried about someone incorrectly typing out

Re: [swift-evolution] [Review] SE-0077 v2: Improved operator declarations

On Thu, Jun 30, 2016 at 2:09 PM, Matthew Johnson wrote: > > On Jun 30, 2016, at 1:48 PM, Xiaodi Wu wrote: > > As Anton mentioned earlier, I feel the same way with respect to naming. No > need to reiterate the points already made, but I do want to chime in on the > topic of rarely used syntax. >

Re: [swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines

on Wed Jun 29 2016, Erica Sadun wrote: >> On Jun 29, 2016, at 3:59 PM, Xiaodi Wu via swift-evolution >> wrote: >> >> On Wed, Jun 29, 2016 at 4:50 PM, David Sweeris > > wrote: >> That’s the “as proposed” usage for getting the size of a value (from >> https://gist.gi

Re: [swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines

On Thu, Jun 30, 2016 at 2:30 PM, Dave Abrahams wrote: > > on Wed Jun 29 2016, Erica Sadun wrote: > > >> On Jun 29, 2016, at 3:59 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > >> > >> On Wed, Jun 29, 2016 at 4:50 PM, David Sweeris > wrote:

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

> On 30 Jun 2016, at 21:20, Xiaodi Wu wrote: > > On Thu, Jun 30, 2016 at 2:14 PM, Taras Zakharko via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > > > On 30 Jun 2016, at 20:26, Chris Lattner via swift-evolution > > mailto:swift-evolution@swift.org>> wrote: > > > > Hello Swift

Re: [swift-evolution] [Review] SE-0110: Distinguish between single-tuple and multiple-argument function types

> * What is your evaluation of the proposal? +1 > * Is the problem being addressed significant enough to warrant a change > to Swift? Yes > * Does this proposal fit well with the feel and direction of Swift? Yes > * If you have used other languages or libraries with

Re: [swift-evolution] [Review] SE-0110: Distinguish between single-tuple and multiple-argument function types

> * What is your evaluation of the proposal? +1. The behaviour we are calrifying has always been fairly confusing to me. I think it comes from when arguments and tuples were semantically equivalent. Now that this is not the case anymore, this proposal seems logical. > * Is the prob

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

I’d also like to know what the answer to this is before giving my vote for or against the proposal. > On 30 Jun 2016, at 20:37, Sean Heber via swift-evolution > wrote: > > This mostly makes sense to me and it seems like mostly a good idea, but take > this example: > > func doSomething(x: Int

Re: [swift-evolution] [Post Swift 3] [Proposal] Introducing `group` mechanism

> On 30 Jun 2016, at 11:22, Adrian Zubarev via swift-evolution > wrote: > It is an interesting suggestion to use extensions that way, but how would you > nest and create diffrent label pathes with extensions? > > We also cannot nest extensions (yet) and when it comes to conformances the > ac

[swift-evolution] Allowing enum extensions to also be able to expand case options

I am finding myself in a situation where the most elegant "swifty" solution would be to allow enum extensions to add to existing case options. For example lets say I'm using a library that has the following enum defined: enum MyDirection { case east, west } My app for example also makes u

Re: [swift-evolution] Allowing enum extensions to also be able to expand case options

By itself, this would break switch statements, since they have to be exhaustive. If anyone has any ideas about how to fix that, I'm all ears. - Dave Sweeris > On Jun 30, 2016, at 14:58, Edward Valentini via swift-evolution > wrote: > > > I am finding myself in a situation where the most eleg

Re: [swift-evolution] Allowing enum extensions to also be able to expand case options

Existing switch statements would have to be modified to add a default statement. Additionally enums could be marked final to disallow case option expansion On Jun 30, 2016, at 16:04, David Sweeris wrote: > > By itself, this would break switch statements, since they have to be > exhaustive

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

On 30.06.2016 21:56, Scott James Remnant via swift-evolution wrote: They already *are* type compatible. This works right now: var a : (ofHits: Int, forRuns: Int) -> Bool = meetsBattingAverage a = sinkBattleship // ??? a(ofHits: 1, forRuns: 2) Your proposal does not make it clear that this work

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

This is a false dichotomy. The language can support tuples without requiring that function application be modeled in terms of tuples. That ship has sailed long ago, and there is no reason to revisit it without a compelling reason (and "function argument lists look sort of like tuples" is not to me

Re: [swift-evolution] Allowing enum extensions to also be able to expand case options

I think we have the same question as with the "sealed" classes by default proposal. To allow or not extension of the public API by the user (at least by default). El jue., 30 jun. 2016 a las 16:10, Edward Valentini via swift-evolution (< swift-evolution@swift.org>) escribió: > > Existing switch s

Re: [swift-evolution] [Post Swift 3] [Proposal] Introducing `group` mechanism

How about adding attributes on extensions (just bikeshedding), because to me it’s not clear if you’re creating a class/static access label or for an instance of that type? Nesting extensions would become useful for the sake of access labels. struct A { public extension Self.foo {

Re: [swift-evolution] Allowing enum extensions to also be able to expand case options

I've had a draft of a proposal lying around for a while which addresses exactly this, but I haven't gotten around to sending it out for comments yet. Link . Would appreciate if you guys took a look. Dan Appel Pasted inline below

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

On 30.06.2016 21:37, Sean Heber via swift-evolution wrote: This mostly makes sense to me and it seems like mostly a good idea, but take this example: func doSomething(x: Int, y: Int) -> Bool { return true } let x = doSomething x(10, 10) Is it then legal to do this?: x(blahblah:10, totallyOffT

Re: [swift-evolution] [Pitch] Remove destructive consumption from Sequence

> On 30 Jun 2016, at 18:26, Dave Abrahams wrote: > > Q: Why should there be indices on an infinite multipass sequence? > A: Because the operations on indices apply equally well whether the > sequence is finite or not. Find the index of a value in the > sequence, slice the sequence, find a

Re: [swift-evolution] [Discussion] A Problem With SE-0025?

> On Jun 30, 2016, at 9:48, Xiaodi Wu wrote: > > Cool. FWIW, even in such a world, I wonder if the conformance needs to be > regarded as `fileprivate`: > > In all cases where a private protocol is visible and conformance can be > declared, the protocol's access level would be-- > > - effecti

[swift-evolution] [Accepted] SE-0103: Make non-escaping closures the default

Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0103-make-noescape-default.md Hello Swift Community, The review of "SE-0103: Make non-escaping closures the default" ran from June 21...27. The proposal is *accepted* for Swift 3 with a minor revision: instead of a “

  1   2   >