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

[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

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

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

[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

[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

[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

[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

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

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

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 >> > wrote: >> >>> >>> On 13 Jul 2016, at 19:59, Daniel A. Steffen >>

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

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

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: >

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

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

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

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 > >

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

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 >> > wrote: >> >> >>> On Jul 13, 2016, at 9:18 , Karl via

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

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 >> > wrote: >> >> #1 - >> >> Currently, DispatchQueue.after() takes an absolute time as the “after”

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

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: >>

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

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

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 >> > wrote: >> >> nuances about the clock (basically, whether or not

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

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

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

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

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

[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

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

[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

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

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.

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

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

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

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

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

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

[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

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 { >

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

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

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

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

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

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

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

[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

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

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

>* What is your evaluation of the proposal? -1. I'd like to split my review of this proposal in its two features: The loss of extensions as an access modifier grouping construct is what I really dislike. IMHO, extensions are a natural way to express that, and I wouldn't want to have

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

> On Jul 12, 2016, at 7:06 PM, Dave Abrahams via swift-evolution > wrote: > > > on Tue Jul 12 2016, Jacob Bandes-Storch > wrote: > >>> >>> Proposal link: >>> >>>

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

Whoops. +swift-evolution ~Robert Widmann 2016/07/12 22:34、Chris Lattner のメッセージ: > You can respond on list as part of the swift team if you’d like :-) > > -Chris > >> On Jul 12, 2016, at 10:33 PM, Robert Widmann >> wrote: >> >> * What is your

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

> Am 12.07.2016 um 22:54 schrieb Jean-Daniel Dupas via swift-evolution > : > > If you can’t trust a developer, how could you use its library ? I guess you're getting this wrong, and maybe on purpose: Thrusting a developer is competent and tries to do a good job is on