Re: [swift-evolution] Learning from SE-0025, a breeding group for Swift proposals

> Once someone starts shipping something that depends on a feature they get > very grumpy when it gets taken away. Well, it happened before, and people's life went on without tuple splat and currying… ;-) I don't think an open Beta would add that much value on its own — but imho the aspect of t

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0166: Swift Archival & Serialization

> On Apr 20, 2017, at 10:08 AM, Tony Parker via swift-evolution > wrote: > > * The above will allow those protocols, plus Encodable, Decodable, typealias > Codable, Encoder, Decoder, CodingKey, struct CodingUserInfoKey to be part of > the standard library (not in Foundation), resolving the co

Re: [swift-evolution] Learning from SE-0025, a breeding group for Swift proposals

> On Apr 18, 2017, at 12:00 AM, David Hart via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > > Here's my rough idea: > The Swift compiler gains a new off-by-default `next` version triggerable with > the `-swift-version next` flag. > All controversial proposals start their implem

Re: [swift-evolution] [Accepted] SE-0169: Improve Interaction Between `private` Declarations and Extensions

> On 21 Apr 2017, at 01:31, Douglas Gregor via swift-evolution > wrote: > > >>> On Apr 20, 2017, at 3:39 PM, John McCall wrote: >>> >>> On Apr 20, 2017, at 6:35 PM, Xiaodi Wu via swift-evolution >>> wrote: On Thu, Apr 20, 2017 at 5:03 PM, Douglas Gregor wrote: >> On

Re: [swift-evolution] [Review] SE-0172: One-sided Ranges

I would add that I expect variadic generics to be used less often than one-sided ranges, and also to be a more complex and advanced feature. Both of these suggest that one-sided ranges deserve the simpler, friendlier syntax. -- Brent Royal-Gordon Sent from my iPhone > On Apr 20, 2017, at 4:38

Re: [swift-evolution] [Accepted] SE-0169: Improve Interaction Between `private` Declarations and Extensions

> On Apr 20, 2017, at 7:31 PM, Douglas Gregor wrote: >> On Apr 20, 2017, at 3:39 PM, John McCall > > wrote: >> >>> On Apr 20, 2017, at 6:35 PM, Xiaodi Wu via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> On Thu, Apr 20, 2017 at 5:03 PM, Douglas Greg

[swift-evolution] Add MutableCollection.swap

Hi Swift community, Another pitch, this time related to the ownership manifesto. Add MutableCollection.swap(_:with:) Proposal: SE- Authors: Ben Cohen Review Manager: TBD Status: Awaiting review Introduction As part of the introduction of the Law of Exclu

Re: [swift-evolution] [Review] SE-0172: One-sided Ranges

> On Apr 20, 2017, at 6:36 AM, Matt Whiteside wrote: > > I do like this proposed one-sided range syntax, but a while back it was > pointed out that it might conflict with a candidate syntax for variadic > generics. Has anything changed there? It does conflict with the straw man syntax descri

Re: [swift-evolution] [Accepted] SE-0169: Improve Interaction Between `private` Declarations and Extensions

On Thu, Apr 20, 2017 at 6:31 PM, Douglas Gregor wrote: > > On Apr 20, 2017, at 3:39 PM, John McCall wrote: > > On Apr 20, 2017, at 6:35 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > On Thu, Apr 20, 2017 at 5:03 PM, Douglas Gregor wrote: > >> >> >> On Apr 20, 2017, at

Re: [swift-evolution] [Accepted] SE-0169: Improve Interaction Between `private` Declarations and Extensions

> On Apr 20, 2017, at 3:39 PM, John McCall wrote: > >> On Apr 20, 2017, at 6:35 PM, Xiaodi Wu via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> On Thu, Apr 20, 2017 at 5:03 PM, Douglas Gregor > > wrote: >> >> >>> On Apr 20, 2017, at 11:33 AM, Jordan

Re: [swift-evolution] [Pitch] Improve the API Design Guidelines about protocol naming

Just to play devil’s advocate, depending on how the protocol actually works, you could claim it *is* a RangeExpression (that is, it is something that can be turned into a range). That was one of the proposals… I lost track of which one was accepted. Thanks, Jon > On Apr 19, 2017, at 8:55 A

Re: [swift-evolution] [Accepted] SE-0155: Normalize Enum Case Representation

Sent from my iPhone > On 20 Apr 2017, at 23:15, John McCall wrote: > > >> On Apr 20, 2017, at 5:50 PM, Goffredo Marocchi wrote: >> >> One thing I wanted to point out and that was a non trivial issue last year >> and that the core team did discuss and agreed to revisit (if I remember the >>

Re: [swift-evolution] [Accepted] SE-0169: Improve Interaction Between `private` Declarations and Extensions

> On Apr 20, 2017, at 6:35 PM, Xiaodi Wu via swift-evolution > wrote: > On Thu, Apr 20, 2017 at 5:03 PM, Douglas Gregor > wrote: > > >> On Apr 20, 2017, at 11:33 AM, Jordan Rose > > wrote: >> >> >>> On Apr 18, 2017, at 20:40, Douglas Gr

Re: [swift-evolution] [Accepted] SE-0169: Improve Interaction Between `private` Declarations and Extensions

On Thu, Apr 20, 2017 at 5:03 PM, Douglas Gregor wrote: > > > On Apr 20, 2017, at 11:33 AM, Jordan Rose wrote: > > > On Apr 18, 2017, at 20:40, Douglas Gregor via swift-evolution < > swift-evolution@swift.org> wrote: > > This makes the private/fileprivate distinction meaningful for extensions. >

Re: [swift-evolution] [Accepted] SE-0155: Normalize Enum Case Representation

> On Apr 20, 2017, at 5:50 PM, Goffredo Marocchi wrote: > > One thing I wanted to point out and that was a non trivial issue last year > and that the core team did discuss and agreed to revisit (if I remember the > thread update by Chris Lattner last year): > > >> Note that since the labels

Re: [swift-evolution] [Accepted] SE-0169: Improve Interaction Between `private` Declarations and Extensions

> On Apr 20, 2017, at 11:33 AM, Jordan Rose wrote: > > >> On Apr 18, 2017, at 20:40, Douglas Gregor via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> This makes the private/fileprivate distinction meaningful for extensions. I >> think also bans the use of "private" at g

Re: [swift-evolution] [Accepted] SE-0155: Normalize Enum Case Representation

One thing I wanted to point out and that was a non trivial issue last year and that the core team did discuss and agreed to revisit (if I remember the thread update by Chris Lattner last year): > Note that since the labels aren't part of a tuple, they no longer participate > in type checking, b

[swift-evolution] Rationalizing Sequence end-operation names

What's the status on this proposal? https://github.com/apple/swift-evolution/blob/master/proposals/0132-sequence-end-ops.md It's currently marked as deferred due to time constraints leading up to the release of Swift 3. Is this still in scope for Swift 4, given it's a breaking change?__

Re: [swift-evolution] [Accepted] SE-0155: Normalize Enum Case Representation

> On Apr 20, 2017, at 4:39 PM, Xiaodi Wu wrote: > > On Thu, Apr 20, 2017 at 3:20 PM, John McCall via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > Proposal Link: > https://github.com/apple/swift-evolution/blob/master/proposals/0155-normalize-enum-case-representation.md > >

Re: [swift-evolution] [Accepted] SE-0155: Normalize Enum Case Representation

On Thu, Apr 20, 2017 at 3:20 PM, John McCall via swift-evolution < swift-evolution@swift.org> wrote: > Proposal Link: https://github.com/apple/swift-evolution/blob/ > master/proposals/0155-normalize-enum-case-representation.md > > Hello Swift Community, > > The review of SE-0155 "Normalize Enum Ca

[swift-evolution] [Accepted] SE-0155: Normalize Enum Case Representation

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0155-normalize-enum-case-representation.md Hello Swift Community, The review of SE-0155 "Normalize Enum Case

Re: [swift-evolution] [Pitch] Improve the API Design Guidelines about protocol naming

Sorry if my original reply didn’t come across as neutral as I had hoped. I actually like the Protocol suffix and have used it when the name I wanted to use was already taken by a concrete type. I’m not sure yet if a Protocol suffix would “always” be the right choice when a protocol can't be na

Re: [swift-evolution] [Accepted] SE-0168: Multi-Line String Literals

On Thu, Apr 20, 2017 at 11:48 AM, Adrian Zubarev < adrian.zuba...@devandartist.com> wrote: > The multi-line string literal as it’s accepted right now only allows > pretty code generation with smaller lines. > This statement does not make sense to me. Multiline string literals allow (with the unav

Re: [swift-evolution] [Accepted] SE-0168: Multi-Line String Literals

> On 20 Apr 2017, at 17:48, Adrian Zubarev wrote: > > Some words about the trailing precision. Joe said that we could use \("") as > workaround, but if I recall correctly literals are banned from the > interpolation itself, which will result in us doing something like this: > > let end = "" >

[swift-evolution] [Pitch] Don't require & for UnsafeRawPointer

Summary: Currently, only mutable values can be passed to UnsafeRawPointer, except for a special case for arrays. That special case should be generalized, allowing any values to be passed to UnsafeRawPointer without using &. The following code shows the inconsistency in passing values to UnsafeR

Re: [swift-evolution] [Accepted] SE-0169: Improve Interaction Between `private` Declarations and Extensions

> On Apr 18, 2017, at 20:40, Douglas Gregor via swift-evolution > wrote: > > This makes the private/fileprivate distinction meaningful for extensions. I > think also bans the use of "private" at global scope for non-nominal types or > extensions thereof. A clarifying update to the proposal i

Re: [swift-evolution] SE-0170: NSNumber bridging and Numeric types

So is it correct to say that for all types T which NSNumber can hold (Double, Float, Int, UInt, ... ) T(exactly: someNSNumber) will succeed if and only if NSNumber(value: T(truncating: someNSNumber)) == someNSNumber holds? > On 20. Apr 2017, at 18:10, Philippe Hausler wrote: >

[swift-evolution] "Universal Error" testing method

I propose adding some kind of mechanism that allows better reporting in unit tests dealing with Universal Errors (and Logic Failures

Re: [swift-evolution] SE-0068 MIA? - Self.classMethod() from instance methods

> On Apr 20, 2017, at 8:13 AM, John Holdsworth via swift-evolution > wrote: > > I was going to have a look at creating a new proposal for this but I see > there already > is one > > and the start of an imple

Re: [swift-evolution] SE-0170: NSNumber bridging and Numeric types

Right. I think we're in vigorous agreement. On Thu, Apr 20, 2017 at 11:11 Philippe Hausler wrote: > On Apr 19, 2017, at 6:09 PM, Xiaodi Wu wrote: > > > > On Wed, Apr 19, 2017 at 6:35 PM, Philippe Hausler > wrote: > >> >> >> On Apr 19, 2017, at 16:17, Xiaodi Wu wrote: >> >> On Wed, Apr 19, 20

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0166: Swift Archival & Serialization

Hi everyone, Thanks for your feedback on this proposal. Based on that plus additional feedback from core team members and others who responded off-thread, we are making the following small adjustments: * KeyedEncoderContainerProtocol, KeyedDecodingContainerProtocol, UnkeyedEncodingContainer, U

Re: [swift-evolution] [Accepted] SE-0168: Multi-Line String Literals

Exactly, thank you for the clarification. That is the correct decision IMO. :) Here is the formatted version of the example from my last reply: https://gist.github.com/DevAndArtist/345ce0920de62349c1079e18201aea94 --  Adrian Zubarev Sent with Airmail Am 20. April 2017 um 18:58:07, Joe Groff v

Re: [swift-evolution] [Accepted] SE-0168: Multi-Line String Literals

> On Apr 19, 2017, at 3:27 PM, Xiaodi Wu wrote: > > On Wed, Apr 19, 2017 at 5:24 PM, Joe Groff > wrote: > > > On Apr 19, 2017, at 3:16 PM, Xiaodi Wu via swift-evolution > > mailto:swift-evolution@swift.org>> wrote: > > > > We had a very full debate about which way was

Re: [swift-evolution] [Pitch] Improve the API Design Guidelines about protocol naming

Yeah, I wasn't trying to take a side, just identifying where David might have heard "Protocol" in an official Apple presentation. I'm staying out of this one. :-) Jordan > On Apr 20, 2017, at 00:21, Gwendal Roué wrote: > > Well, IteratorProtocol, LazySequenceProtocol weren't imported from Obj

Re: [swift-evolution] [Accepted] SE-0168: Multi-Line String Literals

The multi-line string literal as it’s accepted right now only allows pretty code generation with smaller lines. The literal itself is not reserved for JSON, XML and similar syntaxes only, which automatically implies the existence of conventions with longer lines. For whatever reasons a developer

Re: [swift-evolution] SE-0170: NSNumber bridging and Numeric types

> On Apr 19, 2017, at 6:09 PM, Xiaodi Wu wrote: > > > > On Wed, Apr 19, 2017 at 6:35 PM, Philippe Hausler > wrote: > > >> On Apr 19, 2017, at 16:17, Xiaodi Wu > > wrote: >> >> On Wed, Apr 19, 2017 at 6:00 PM, Philippe Hausler >

[swift-evolution] SE-0068 MIA? - Self.classMethod() from instance methods

I was going to have a look at creating a new proposal for this but I see there already is one and the start of an implementation . Is there any chance this is in the pi

[swift-evolution] [Accepted] SE-165: Dictionary & Set Enhancements

Hello Swift Community, The review of SE-165: Dictionary & Set Enhancements ran from April 6...11, 2017. The proposal is accepted with some revisions regarding naming: 1) The key/value sequence of init that does not take a closure resolving key conflicts will be named init(uniqueKeysWithValues:)

Re: [swift-evolution] [Review] SE-0172: One-sided Ranges

I do like this proposed one-sided range syntax, but a while back it was pointed out that it might conflict with a candidate syntax for variadic generics. Has anything changed there? -Matt > On Apr 17, 2017, at 21:40, Douglas Gregor via swift-evolution > wrote: > > Hello Swift community, >

Re: [swift-evolution] [Pitch] Improve the API Design Guidelines about protocol naming

+1 to the proposal, *especially* the addition of the RangeExpression protocol. That being said, I agree with the critiques over the chosen name. I also can't remember where exactly, but I do remember at some point hearing that the -Protocol suffix should be added to protocol names if needed to d

Re: [swift-evolution] [Pitch] Improve the API Design Guidelines about protocol naming

Well, IteratorProtocol, LazySequenceProtocol weren't imported from ObjC. They set a precedent for the -Protocol suffix. Now, even if you don't like RangeProtocol, this doesn't make RangeExpression better. "Expression" and `1...` don't belong to the same level of the language: one is a concept