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

Sent from my iPhone > On 14 Jul 2016, at 04:58, Chris Lattner wrote: > > >> On Jul 9, 2016, at 1:56 AM, Goffredo Marocchi via swift-evolution >> wrote: >> >> >> Sent from my iPhone >> >>> On 9 Jul 2016, at 00:53, Jon Shier wrote: >>> >>> While I can see why removing the labels from the

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

👏 > On 14 Jul 2016, at 06:47, Chris Lattner via swift-evolution > wrote: > > Proposal: > https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md > >

Re: [swift-evolution] [Accepted] SE-0091: Improving operator requirements in protocols

> On Jul 13, 2016, at 8:57 PM, Tony Allevato wrote: > > Thanks Chris! I'm happy that the proposal was well-received, and thanks to > Doug for the great improvements for revision 2. > > Related, does the acceptance of this proposal imply the removal of the named > methods from FloatingPoint an

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

Proposal: https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md Shortly after SE-0111 was accepted last week, several people newly noticed the proposal and started a discussion about how it appears to be a regression for closure parameters (e.

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

> On Jul 9, 2016, at 1:56 AM, Goffredo Marocchi via swift-evolution > wrote: > > > Sent from my iPhone > > On 9 Jul 2016, at 00:53, Jon Shier > wrote: > >> While I can see why removing the labels from the type system would be a good >> idea, I don’t see why callin

Re: [swift-evolution] [Accepted] SE-0091: Improving operator requirements in protocols

Thanks Chris! I'm happy that the proposal was well-received, and thanks to Doug for the great improvements for revision 2. Related, does the acceptance of this proposal imply the removal of the named methods from FloatingPoint and Arithmetic in favor of static operators, or do we need a separate p

[swift-evolution] [Accepted] SE-0091: Improving operator requirements in protocols

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0091-improving-operators-in-protocols.md The second review of "SE-0091: Improving operator requirements in protocols" ran from July 7...12, 2016. The proposal has been *accepted with revision*: The second iteration of

[swift-evolution] [Accepted] SE-0107: UnsafeRawPointer API

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0107-unsaferawpointer.md The review of "SE-0107: UnsafeRawPointer API" ran from June 28 ... July 10, 2016. The proposal has been *accepted*: The community and core team agree that this proposal clarifies the rules aro

[swift-evolution] [Accepted] SE-0118: Closure Parameter Names and Labels

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0118-closure-parameter-names-and-labels.md The review of "SE-0118: Closure Parameter Names and Labels " ran from July 5...11, 2016. The proposal has been *accepted with modifications*: The proposal has been very well

Re: [swift-evolution] [Proposal] Allow Static Function Properties to Satisfy Static Function Protocol Requirements

Hey Chris, thanks so much for the feedback! > This is an additive proposal, thus out of scope for Swift 3. For sure! Definitely didn’t expect this to land pre-3.0 :) > Beyond that, as someone down thread mentioned, the major thing missing here is a strong motivation for *why* we should do this.

Re: [swift-evolution] [swift-evolution-announce] [Review #2] SE-0101: Reconfiguring sizeof and related functions into a unified MemoryLayout struct

on Wed Jul 13 2016, Brent Royal-Gordon wrote: >> On Jul 12, 2016, at 4:53 PM, Chris Lattner wrote: >> >> * What is your evaluation of the proposal? > > I think grouping these into a type is a sensible approach, but I don't > like that it allows the creation of meaningless MemoryLayout > i

[swift-evolution] [Pitch] `Int.init(ObjectIdentifier)` and `UInt.init(ObjectIdentifier)` should have a `bitPattern:` label

Int.init(ObjectIdentifier) and UInt.init(ObjectIdentifier) should have a 'bitPattern:’ label to make it clear at the use site that we interpret the value as a bit pattern. In Swift we have ObjectIdentifier values which uniquely identify a class instance or metatype. They are implemented as a st

Re: [swift-evolution] [Idea][Swift 3] Change 'DispatchQueue.after' to take a relative time + clock (with default). Maybe replace clocks with an enum?

> On 13 Jul 2016, at 20:04, Pierre Habouzit via swift-evolution > wrote: > > I strongly disagree that the two forms should be named differently, it’s even > more confusing that if you use after() you get one clock and at() the other. > Also when we will add a 3rd clock to dispatch, it just st

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

I’m still not fully convinced about fully removing the access to the metatype. If you look at Ericas and Daves current proposal for MemoryLayout it would completely break and it would become impossible to build something like this. And yes I borrowed the idea of putting properties like size into

Re: [swift-evolution] [Idea][Swift 3] Change 'DispatchQueue.after' to take a relative time + clock (with default). Maybe replace clocks with an enum?

> On 13 Jul 2016, at 21:04, Pierre Habouzit wrote: > >> On Jul 13, 2016, at 11:42 AM, Karl via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >>> >>> On 13 Jul 2016, at 19:59, Daniel A. Steffen >> > wrote: >>> >>> I’m confused, that is what we have in

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

An even better explanation of my suggestion: instead of *sealing* T.Type, I suggest to *rename* it to Type, formally turning it into a struct, and then add size and align properties to it. And regardless of how you interpret it, I suggest to remove .Type notation. > In Swift, only class instances

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

Okay I get it now. You meant the size for a metatype sizeof(T.Type.self). This is indeed 8 bytes, at least not for optimized Bool (as you showed). Internally, Type contains an Int, i.e. identifier of a type. For every type, compiler must choose a different identifier We can already implement thi

Re: [swift-evolution] [Idea][Swift 3] Change 'DispatchQueue.after' to take a relative time + clock (with default). Maybe replace clocks with an enum?

> On Jul 13, 2016, at 11:42 AM, Karl via swift-evolution > wrote: > >> >> On 13 Jul 2016, at 19:59, Daniel A. Steffen > > wrote: >> >> I’m confused, that is what we have in the current version (the argument >> label is part of the overall method name): asyncAfter(deadli

Re: [swift-evolution] [Pitch] Giving functions default return values

On Wed, Jul 13, 2016 at 1:14 PM, Tim Vermeulen via swift-evolution < swift-evolution@swift.org> wrote: > I thought that was mainly about former proposals in the Github repo, but > I’ll gladly bring this up again at a more appropriate time. > > To address your message: I wouldn’t really want guard

Re: [swift-evolution] [swift-evolution-announce] [Review #2] SE-0091: Improving operator requirements in protocols

On Wed, Jul 13, 2016 at 1:14 PM, Douglas Gregor via swift-evolution < swift-evolution@swift.org> wrote: > > On Jul 12, 2016, at 10:35 AM, Jordan Rose wrote: > > [Proposal: > https://github.com/apple/swift-evolution/blob/master/proposals/0091-improving-operators-in-protocols.md > ] > > I definitel

Re: [swift-evolution] [Idea][Swift 3] Change 'DispatchQueue.after' to take a relative time + clock (with default). Maybe replace clocks with an enum?

> On 13 Jul 2016, at 19:59, Daniel A. Steffen wrote: > > I’m confused, that is what we have in the current version (the argument label > is part of the overall method name): asyncAfter(deadline:) vs > asyncAfter(wallDeadline:), which is consistent with all the other labels of > deadline argum

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

2016-07-13 20:19 GMT+03:00 Adrian Zubarev via swift-evolution < swift-evolution@swift.org>: > > Am 13. Juli 2016 um 18:30:53, Anton Zhilin (antonyzhi...@gmail.com) > schrieb: > > I see model of Type as follows: > >1. Values of Type are identifiers of types (8 bytes, I guess) >2. All used id

Re: [swift-evolution] [Pitch] Giving functions default return values

I thought that was mainly about former proposals in the Github repo, but I’ll gladly bring this up again at a more appropriate time. To address your message: I wouldn’t really want guard else { } to be valid code. The default return value is simply returned if the end of the function body is r

Re: [swift-evolution] [swift-evolution-announce] [Review #2] SE-0091: Improving operator requirements in protocols

> On Jul 12, 2016, at 10:35 AM, Jordan Rose wrote: > > [Proposal: > https://github.com/apple/swift-evolution/blob/master/proposals/0091-improving-operators-in-protocols.md > > > ] > > I

Re: [swift-evolution] [Review] SE-0123: Disallow coercion to optionals in operator arguments

I concur with Joe Groff and John McCall, this proposal does not seem to be the right approach. What I would really like is the complete elimination of implicit coercion to Optional (implicit type conversions are not Swifty!) and the simultaneous introduction of a simple notation for doing so expli

Re: [swift-evolution] [Idea][Swift 3] Change 'DispatchQueue.after' to take a relative time + clock (with default). Maybe replace clocks with an enum?

> On Jul 13, 2016, at 10:08, Karl via swift-evolution > wrote: > >> >> On 13 Jul 2016, at 18:47, Anthony Chivetta via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> >>> On Jul 13, 2016, at 9:18 , Karl via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>>

Re: [swift-evolution] [Review] SE-0119: Remove access modifiers from extensions

> On Jul 13, 2016, at 10:26 AM, Xiaodi Wu via swift-evolution > wrote: > As Jordan mentioned, I don't (and I think other people don't) think of > extensions as their own entities, as they can't be referred to and have no > runtime representation. In that mental model, there isn't such a thing a

Re: [swift-evolution] [Idea][Swift 3] Change 'DispatchQueue.after' to take a relative time + clock (with default). Maybe replace clocks with an enum?

> On 13 Jul 2016, at 18:56, Pierre Habouzit wrote: > >> On Jul 13, 2016, at 9:18 AM, Karl via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> #1 - >> >> Currently, DispatchQueue.after() takes an absolute time as the “after” >> parameter. This makes it hard to understand h

Re: [swift-evolution] [Review] SE-0119: Remove access modifiers from extensions

As Jordan mentioned, I don't (and I think other people don't) think of extensions as their own entities, as they can't be referred to and have no runtime representation. In that mental model, there isn't such a thing as "an extension being public." Instead, the access modifier is just a shorthand d

Re: [swift-evolution] [Review] SE-0119: Remove access modifiers from extensions

> On Jul 13, 2016, at 8:46 AM, Xiaodi Wu via swift-evolution > wrote: > > > >> On Wed, Jul 13, 2016 at 4:04 AM, Rod Brown via swift-evolution >> wrote: >> Proposal link: >> https://github.com/apple/swift-evolution/blob/master/proposals/0119-extensions-access-modifiers.md >> >>> * Wha

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

Am 13. Juli 2016 um 18:30:53, Anton Zhilin (antonyzhi...@gmail.com) schrieb: I see model of Type as follows: Values of Type are identifiers of types (8 bytes, I guess) All used identifiers are contained in Type Type contains a subset of those identifiers I can’t follow your though here. Is this a

Re: [swift-evolution] [Review] SE-0123: Disallow coercion to optionals in operator arguments

> On Jul 13, 2016, at 10:06 AM, Joe Groff via swift-evolution > wrote: > -1. This feels like a band-aid rather than a well-considered fix to the > issues raised in the proposal. I don't see what makes operators as a class of > functions more or less susceptible to these surprising optional upca

Re: [swift-evolution] [Idea][Swift 3] Change 'DispatchQueue.after' to take a relative time + clock (with default). Maybe replace clocks with an enum?

> On 13 Jul 2016, at 18:47, Anthony Chivetta via swift-evolution > wrote: > > >> On Jul 13, 2016, at 9:18 , Karl via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> nuances about the clock (basically, whether or not it pauses during system >> sleep) are edge-cases which c

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0119: Remove access modifiers from extensions

Am 13. Juli 2016 um 18:49:11, Jordan Rose (jordan_r...@apple.com) schrieb: Hi, Adrian. I have to agree with everyone else that the proposal is unclear. “Remove access modifiers from extensions” sounds like you just aren’t allowed to write them at all, but your proposal seems to be more “access

Re: [swift-evolution] [Review] SE-0123: Disallow coercion to optionals in operator arguments

-1. This feels like a band-aid rather than a well-considered fix to the issues raised in the proposal. I don't see what makes operators as a class of functions more or less susceptible to these surprising optional upcasts. Removing the comparison operators for optionals will resolve the issue wi

Re: [swift-evolution] [Idea][Swift 3] Change 'DispatchQueue.after' to take a relative time + clock (with default). Maybe replace clocks with an enum?

> On Jul 13, 2016, at 9:18 AM, Karl via swift-evolution > wrote: > > #1 - > > Currently, DispatchQueue.after() takes an absolute time as the “after” > parameter. This makes it hard to understand how to use it; you need to go > digging through generated interfaces to find out what a ‘Dispatch

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0119: Remove access modifiers from extensions

[Proposal: https://github.com/apple/swift-evolution/blob/master/proposals/0119-extensions-access-modifiers.md ] Hi, Adrian. I have to agree with everyone else that the proposal is unclear. “Remove access modifiers from extensions” sounds like you just aren’t allowed to write them at all, but y

Re: [swift-evolution] [Idea][Swift 3] Change 'DispatchQueue.after' to take a relative time + clock (with default). Maybe replace clocks with an enum?

> On Jul 13, 2016, at 9:18 , Karl via swift-evolution > wrote: > > nuances about the clock (basically, whether or not it pauses during system > sleep) are edge-cases which can be handled for the majority of users with a > sensible default value I’m going to stay out of the naming part of the

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

We removed "of" from the final version: https://github.com/apple/swift-evolution/blob/master/proposals/0101-standardizing-sizeof-naming.md And moved it to "If for some reason, the core team deci

[swift-evolution] [Accepted] SE-0086 "Drop NS Prefix in Swift Foundation"

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0086-drop-foundation-ns.md The review of SE-0086 "Drop NS Prefix in Swift Foundation” ran from May 9…16, 2016. The proposal is *accepted*. This proposal has evolved greatly from a single bullet item in the original p

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

I see model of Type as follows: 1. Values of Type are identifiers of types (8 bytes, I guess) 2. All used identifiers are contained in Type 3. Type contains a subset of those identifiers 4. Type are usually created with default constructor Type() 5. Upcasting uses constructor init(u

[swift-evolution] [Idea][Swift 3] Change 'DispatchQueue.after' to take a relative time + clock (with default). Maybe replace clocks with an enum?

#1 - Currently, DispatchQueue.after() takes an absolute time as the “after” parameter. This makes it hard to understand how to use it; you need to go digging through generated interfaces to find out what a ‘DispatchTime’ is and how you construct it (by getting the .now() and adding a DispatchT

Re: [swift-evolution] [swift-build-dev] Proposal: SwiftPM Target Access Control

On Wed, Jul 13, 2016 at 9:27 PM, Anders Bertelrud wrote: > Thanks for taking the initiative for this, Ankit. It's a very welcome > improvement. > > Comments inline. > > On 2016-07-12, at 11.15, Ankit Agarwal via swift-build-dev < > swift-build-...@swift.org> wrote: > > To mark a target as export

Re: [swift-evolution] [swift-dev] Bugs not reproducible on master

Can't speak for everybody else, but I leave them a comment letting them know, try to find a pull request or commit that would have fixed it and close it if I can find one. Otherwise, a lot of times IBM's exhaustive catalogue of Swift releases on bluemix can usually reproduce tricky SRs. ~Rober

Re: [swift-evolution] [swift-build-dev] Proposal: SwiftPM Target Access Control

Thanks for taking the initiative for this, Ankit. It's a very welcome improvement. Comments inline. On 2016-07-12, at 11.15, Ankit Agarwal via swift-build-dev wrote: > To mark a target as exported/public I propose PackageDescription's Target > gains a flags property which would be a Set of t

Re: [swift-evolution] [Pitch] Giving functions default return values

Hi Tim, the core team asked us to defer any discussion on post-Swift-3 related proposals. That said, there have been several discussion around this topic (in the past few months) and I believe the general attitude towards them was negative, due to it leading to statements such as guard else

Re: [swift-evolution] [Review] SE-0119: Remove access modifiers from extensions

On Wed, Jul 13, 2016 at 4:04 AM, Rod Brown via swift-evolution < swift-evolution@swift.org> wrote: > Proposal link: > https://github.com/apple/swift-evolution/blob/master/proposals/0119-extensions-access-modifiers.md > > * What is your evaluation of the proposal? > > -1. Extensions appear to me to

Re: [swift-evolution] Fixing the confusion between non-mutating algorithms and single-pass sequences

I also thought on the problem, and I agree with your solution. It keeps things simple. I agree with this specific name -- IterableOnce (not IterableAtLeastOnce). IterableOnce contains Iterable -- and that plays very nicely with IteratorProtocol name. IterableOnce is not a single word, but it's not

Re: [swift-evolution] [Review] SE-0119: Remove access modifiers from extensions

> > * What is your evaluation of the proposal? > -1. I think the proposal has great technical merit; if implemented, it would improve the developer experience and pave the way for other improvements in expressivity in the future. However, the proposal doesn't do what it says on the tin (ak

Re: [swift-evolution] [swift-build-dev] Proposal: SwiftPM Target Access Control

> On Jul 13, 2016, at 1:56 AM, Honza Dvorsky wrote: > > Very happy to see this proposal, thanks Ankit for pushing it forward! I can't > wait to be able to hide many example executables in my packages, as I've been > getting a steady stream of complaints from people being annoyed about the > p

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

Okay I’m convinced on that one, but do we really want to give up being able to construct an instance from an metatype instance? (Personally I’d keep it as an optional feature.) There are more than 7000 search results inside swift repository for .Type. I looked up a few of them and I found an in

[swift-evolution] [Pitch] Giving functions default return values

This idea is purely additive and isn’t to be considered for Swift 3. Oftentimes a function has a very obvious default argument to fall back on. If the return value is optional, this is generally nil. If the return value is Bool, it’s probably `false`. Often this fallback value is returned at the

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

2016-07-13 15:02 GMT+03:00 Adrian Zubarev via swift-evolution < swift-evolution@swift.org>: > > To answer your question, we still need the metatype to access initializer > and static member of that type. If we’d drop T.Type completely, we’d lose > functionality to do so. > > protocol A { > init

Re: [swift-evolution] [Review] SE-0120: Revise 'partition' Method Signature

* What is your evaluation of the proposal? +1; I like the new design, and I think once in a blue moon I may actually use the new API. I remember looking up partition in the stdlib docs, sighing and moving on once or twice. It seemed easier to write an explicit loop than to hammer my

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

> On Jul 11, 2016, at 3:51 PM, Károly Lőrentey via swift-evolution > wrote: > > - Annoyance: People will need to remember to manually add an extra keyword to > their public classes whenever they want to allow subclassing. People who want > to always allow cross-module subclassing will always h

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

This isn’t a full proposal (yet). We still can change things. I didn’t consider everything and can’t to that on my own. Feedback is welcome. To answer your question, we still need the metatype to access initializer and static member of that type. If we’d drop T.Type completely, we’d lose functi

Re: [swift-evolution] [swift-evolution-announce] [Review #2] SE-0101: Reconfiguring sizeof and related functions into a unified MemoryLayout struct

> On Jul 12, 2016, at 4:53 PM, Chris Lattner wrote: > > * What is your evaluation of the proposal? I think grouping these into a type is a sensible approach, but I don't like that it allows the creation of meaningless MemoryLayout instances. The simplest fix would be to make `MemoryLayou

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

Why can't we drop metatypes T.Type with your proposal? Do they bring some extra capabilities over Type struct? ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0121: Remove `Optional` Comparison Operators

> On 12 Jul 2016, at 19:26, Chris Lattner via swift-evolution > wrote: > > * What is your evaluation of the proposal? Strongly in favour. > * Is the problem being addressed significant enough to warrant a change > to Swift? Yes, though it seems like a small change it removes an

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

Here is a part of a draft I put together in case we should go for a review on this. Here is the formatted version if you cannot read it here: https://gist.github.com/DevAndArtist/a8d11011a376d47d0afc941017e64c75 Proposed solution I propose to seal T.Type into a standalone type Type and disallo

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

I think you missed that I actually agree with all your points. My point was merely regarding “pre-breaking” which I thought wasn’t a relevant term. I think a far more appropriate term is “overly limiting”. We are discussing semantics, nonetheless. I actually support the idea that you should be

Re: [swift-evolution] [Review] SE-0119: Remove access modifiers from extensions

Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0119-extensions-access-modifiers.md > * What is your evaluation of the proposal? -1. Extensions appear to me t

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

> Publishing a library is a promise of something. It ought to only be promises > the library author wants to make. If “the truth” is “the implementation in > the current version of the library”, that’s definitely not what a library > author should promise. That’s true for plenty of things, not

Re: [swift-evolution] [swift-build-dev] Proposal: SwiftPM Target Access Control

Very happy to see this proposal, thanks Ankit for pushing it forward! I can't wait to be able to hide many example executables in my packages, as I've been getting a steady stream of complaints from people being annoyed about the polluted compilation log and slower compilation times. However I'm l

[swift-evolution] [Accepted] SE-0109: Remove the Boolean protoco

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0109-remove-boolean.md The second review of "SE-0109: Remove the Boolean protocol" ran from June 28 ... July 4, 2016. The propos

Re: [swift-evolution] An Alternative for Extensibility Modifiers

Imho overall this is a good proposal, yet it saddens me to read this thread, because it's a good proof for the dogmatism I mentioned before: You address all issues of proposal 0117 in a more consistent way with less confusing keywords, even adding some features that are actually handy — but yet