Re: [swift-evolution] [Draft] Fix Private Access Levels

> Le 6 mars 2017 à 19:27, Nevin Brackett-Rozinsky via swift-evolution > a écrit : > > I support this proposal to restore the file-based meaning of “private”. > > Personally, I do not think we need any more fine-grained access level than > this, so I lean toward solution 1 (remove the scoped

Re: [swift-evolution] class indent in swift, history?

It might have to do with C history. Anything inside two curly braces usually had an increased indentation level. I always thought the switch statement was an oddball for not indenting the cases. On Tue, Mar 7, 2017 at 1:42 AM Will Stanton via swift-evolution < swift-evolution@swift.org> wrote: >

Re: [swift-evolution] class indent in swift, history?

I believe the indentation is more a signal for a new scope than curly braces. Swift doesn’t indent its switch cases since they’re a part of the same scope, while nested types and methods are a new scope. Saagar Jha > On Mar 7, 2017, at 05:38, Derrick Ho via swift-evolution > wrote: > > It mi

Re: [swift-evolution] class indent in swift, history?

> On 7 Mar 2017, at 15:24, Saagar Jha via swift-evolution > wrote: > > I believe the indentation is more a signal for a new scope than curly braces. > Swift doesn’t indent its switch cases since they’re a part of the same scope, > while nested types and methods are a new scope. I'm not sure

Re: [swift-evolution] Swift null safety questions

Well, I think that it is far more ingrained into the language and its daily use than you might realize. At the very least, someone should correct the XCode warning that says (to paraphrase) “code does not comple, double click to insert optional here” and create some code-analysis warnings against

[swift-evolution] Swift null safety questions

Hi, I’ve been recently considering Swift on the server-side, and there came up the question, “what happens when a null optional is forcibly unwrapped?” and the answer was clearly that not only would the request crash, but the entire server would also crash, since the server itself is/would be also

Re: [swift-evolution] [Manifesto] Ownership

> On Feb 27, 2017, at 11:08 AM, John McCall wrote: > >> On Feb 25, 2017, at 11:41 AM, plx via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> 1: Collection Composition >> >> As much as the high-level picture is focused on safety, I’d just like to >> request a strong focus on m

Re: [swift-evolution] Swift null safety questions

On Mar 6, 2017, at 7:52 PM, Elijah Thomas Johnson via swift-evolution mailto:swift-evolution@swift.org>> wrote: Says: Fix it: Insert ! Should say: Fix it: Use optional binding. I agree with this in general. I tell people that I’m teaching that unwrapping uses ‘!' for a reason. It should scream

Re: [swift-evolution] [Manifesto] Ownership

> On Mar 7, 2017, at 11:47 AM, plx via swift-evolution > wrote: >> On Feb 27, 2017, at 11:08 AM, John McCall > > wrote: >> >>> On Feb 25, 2017, at 11:41 AM, plx via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> 1: Collection Composition >>> >>> As

Re: [swift-evolution] [Manifesto] Ownership

> On Mar 7, 2017, at 10:02 AM, John McCall via swift-evolution > wrote: > >>> On Mar 7, 2017, at 11:47 AM, plx via swift-evolution >>> wrote: On Feb 27, 2017, at 11:08 AM, John McCall wrote: On Feb 25, 2017, at 11:41 AM, plx via swift-evolution wrote: 1: Collecti

Re: [swift-evolution] Swift null safety questions

How about the proposal of warnings and/or fix-it for unnecessary use of optionals? It seems to me though, that there aren't too many "necessary" uses for forced-unwrapping. Judging from ( https://github.com/apple/swift-evolution/blob/master/proposals/0054-abolish-iuo.md), it was probably added as

[swift-evolution] [Pitch N+1] Submodules and Access Levels

Hi, there are a lot of proposals floating around at the moment and I want to present my point of view. I’ve read most of the discussion, but not everything and instead of replying to all the individual mail, I’ll just add pitch N+1 into the mix. At the current level of discussion I hope that’s

Re: [swift-evolution] [Pitch N+1] Submodules and Access Levels

Ups accidentally sent an old draft, please disregard... -- Martin ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Manifesto] Ownership

> On Mar 7, 2017, at 1:28 PM, jaden.gel...@gmail.com wrote: > On Mar 7, 2017, at 10:02 AM, John McCall via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > >>> On Mar 7, 2017, at 11:47 AM, plx via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: On Feb 27, 2017, at

[swift-evolution] [Pitch] Introducing `Unwrappable` protocol

I have been involved in several separate related draft proposals for discussions that were cut off about 4 months ago. I believe they meet the criteria for Stage 2, but I'm doing a poor job presenting them coherently on-list. Because of that, I'm going to start over here, hopefully pulling in a

Re: [swift-evolution] [Discussion] Simplifying case syntax

I've put together everything I have about cases and unwrapping here: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170306/033588.html So please move the discussion there. Thanks! -- E > On M

Re: [swift-evolution] [Pitch] Introducing `Unwrappable` protocol

Would ‘if let foo = foo’ still be allowed? > On Mar 7, 2017, at 12:14 PM, Erica Sadun via swift-evolution > wrote: > > I have been involved in several separate related draft proposals for > discussions > that were cut off about 4 months ago. I believe they meet the criteria for > Stage 2, >

Re: [swift-evolution] [Pitch] Introducing `Unwrappable` protocol

> On Mar 7, 2017, at 1:31 PM, Jonathan Hull wrote: > > Would ‘if let foo = foo’ still be allowed? > > Existing code should to continue to work with `if let foo = foo`. I don't believe I put anything in-text about removing this, but if you see something let me know. -- E >> On Mar 7, 2017, a

[swift-evolution] [Review] SE-0158 Package Manager Manifest API Redesign

Hello Swift community, The review of "SE-0158 Package Manager Manifest API Redesign" begins now and runs through March 13, 2017. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0158-package-manager-manifest-api-redesign.md Reviews are an i

Re: [swift-evolution] Swift null safety questions

Correct me if I am wrong, but it seems like the main intended use of optionals would be to work with legacy Obj-C code that is missing nullability specifiers. In the rest of the cases, a forced-unwrap is just "syntactic sugar" for a fatal error block or a way to indicate that you have already check

Re: [swift-evolution] [Review] SE-0158 Package Manager Manifest API Redesign

> On 7 Mar 2017, at 21:53, Rick Ballard via swift-evolution > wrote: > > Hello Swift community, > > The review of "SE-0158 Package Manager Manifest API Redesign" begins now and > runs through March 13, 2017. The proposal is available here: > > > https://github.com/apple/swift-evolutio

Re: [swift-evolution] Why doesn't Collection's SubSequence conform to Collection?

> On Feb 24, 2017, at 7:49 AM, Davide Mendolia wrote: > > What's the status of Recursive protocol constraints? it's a feature that will > help the design of a library I'm working on. It’s a surprisingly intricate feature that’s required some major refactoring in the compiler (for the better).

Re: [swift-evolution] [Review] SE-0157: Support recursive constraints on associated types

- What is your evaluation of the proposal? +1 - Is the problem being addressed significant enough to warrant a change to Swift? Yes. Yes. A thousand times, yes. - Does this proposal fit well with the feel and direction of Swift? Yes. - If you have used other languages or librar

Re: [swift-evolution] [Pitch] Introducing `Unwrappable` protocol

I like some of this, but as a single proposal, it does too many things at once. - The `case let .some(foo)` vs. `case .some(let foo)` issue could be a targeted proposal. (I really like this) - The Unwrappable protocol (and keyword) is interesting; it can probably be its own discussion. (feels u

Re: [swift-evolution] [Pitch] Introducing `Unwrappable` protocol

> On Mar 7, 2017, at 3:44 PM, Guillaume Lessard via swift-evolution > wrote: > > I like some of this, but as a single proposal, it does too many things at > once. I deliberately moved it out of proposal format for that reason, so it could be discussed first. > - The `case let .some(foo)` vs

Re: [swift-evolution] [Pitch] Introducing `Unwrappable` protocol

It’s worth mentioning that the normal let binding can be used for pattern matching: let (a, b, c) = foo() This nicely parallels the existing case syntax: if case let .blah(a, b, c) = bar() { … } It would feel inconsistent if the order switched when in a conditional binding. I would prefer th

Re: [swift-evolution] [Pitch] Introducing `Unwrappable` protocol

> On Mar 7, 2017, at 15:30, Erica Sadun wrote: > >> - The `case let .some(foo)` vs. `case .some(let foo)` issue could be a >> targeted proposal. >> (I really like this) > > I put it in as a bug report (link in repo) based on ?Anton's? suggestion but > Jordan says this > isn't similar to norm

Re: [swift-evolution] [Pitch] Introducing `Unwrappable` protocol

> On Mar 7, 2017, at 4:30 PM, Erica Sadun wrote: > > I deliberately moved it out of proposal format for that reason, so it could > be discussed first. I see now. >> - The `case let .some(foo)` vs. `case .some(let foo)` issue could be a >> targeted proposal. >> (I really like this) > > I pu

Re: [swift-evolution] [Discussion] Simplifying case syntax

I don’t fully understand - are you saying to comment on the gist as if it were a discussion forum? -DW > On Mar 7, 2017, at 1:25 PM, Erica Sadun via swift-evolution > wrote: > > I've put together everything I have about cases and unwrapping here: > > https://lists.swift.org/pipermail/swift-e

Re: [swift-evolution] [Pitch] Introducing `Unwrappable` protocol

> On Mar 7, 2017, at 3:49 PM, Jaden Geller via swift-evolution > wrote: > > It’s worth mentioning that the normal let binding can be used for pattern > matching: > let (a, b, c) = foo() > > This nicely parallels the existing case syntax: > if case let .blah(a, b, c) = bar() { … } > It wou

[swift-evolution] [Draft] Remove support for final in protocol extensions

Hey Folks, This draft proposal addresses starter bug SR-1762. I believe this is in scope for Swift 4 since it impacts source compatibility. It's not a very exciting proposal, but I think it will help make Swift a little more consistent. https://gist.github.com/KingOfBrian/6f20c566114ac0ef54c8092d8

Re: [swift-evolution] [Discussion] Simplifying case syntax

Please respond to that email thread rather than this one. Thank you. -- E > On Mar 7, 2017, at 7:25 PM, David Waite wrote: > > I don’t fully understand - are you saying to comment on the gist as if it > were a discussion forum? > > -DW > >> On Mar 7, 2017, at 1:25 PM, Erica Sadun via swift-e

Re: [swift-evolution] [Pitch] Introducing `Unwrappable` protocol

I disagree that the following is better guard unwrap foo else { ... } // simpler? It feels like you are re-using foo which previously was an optional but now is something else. If a variable is a cup, then you'd be reusing a cup that previously had a different drink in it. guard let foo = foo el

Re: [swift-evolution] [Draft] Remove support for final in protocol extensions

It makes sense since protocol do not allow final. It doesn't make much sense to allow the extensions to be exempt from this. Classes that inherit from it can still provide their own implementation of the supposed "final" protocol method which is contradictory to what final means. Protocol extensi

Re: [swift-evolution] [Pitch] Introducing `Unwrappable` protocol

> On Mar 7, 2017, at 12:14 PM, Erica Sadun via swift-evolution > wrote: > > Because of that, I'm going to start over here, hopefully pulling in all the > details > and allowing the community to provide feedback and direction. The following > gist is an amalgam of work I was discussing with Xia

Re: [swift-evolution] [Pitch] Introducing `Unwrappable` protocol

> On Mar 8, 2017, at 2:33 AM, Guillaume Lessard via swift-evolution > wrote: > > >> On Mar 7, 2017, at 4:30 PM, Erica Sadun wrote: >> >> I deliberately moved it out of proposal format for that reason, so it could >> be discussed first. > > I see now. > > >>> - The `case let .some(foo)` v

Re: [swift-evolution] [Pitch] Introducing `Unwrappable` protocol

> On Mar 7, 2017, at 8:59 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> On Mar 7, 2017, at 12:14 PM, Erica Sadun via swift-evolution >> wrote: >> >> Because of that, I'm going to start over here, hopefully pulling in all the >> details >> and allowing the community to provide fee

Re: [swift-evolution] [Pitch] Introducing `Unwrappable` protocol

> On 8 Mar 2017, at 03:27, Greg Parker via swift-evolution > wrote: > > >> On Mar 7, 2017, at 3:49 PM, Jaden Geller via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> It’s worth mentioning that the normal let binding can be used for pattern >> matching: >> let (a, b, c

Re: [swift-evolution] class indent in swift, history?

Hi Will, Good question: the general rationale is that true nesting implies indentation in Swift. Cases are not indented under “switch” because they are part of the switch statement, and, similarly, didSet is part of the property it is defined on. In contrast, nested types really are nested, t

Re: [swift-evolution] [Pitch] Introducing `Unwrappable` protocol

I will attach my comments to Brent’s answer because I echo many of his thoughts: > On 8 Mar 2017, at 05:59, Brent Royal-Gordon via swift-evolution > wrote: > >> On Mar 7, 2017, at 12:14 PM, Erica Sadun via swift-evolution >> wrote: >> >> Because of that, I'm going to start over here, hopeful

Re: [swift-evolution] [Pitch] Introducing `Unwrappable` protocol

> On 7 Mar 2017, at 21:41, Erica Sadun via swift-evolution > wrote: > >> On Mar 7, 2017, at 1:31 PM, Jonathan Hull > > wrote: >> >> Would ‘if let foo = foo’ still be allowed? >> >> > > Existing code should to continue to work with `if let foo = foo`. I don't > believe

Re: [swift-evolution] [Review] SE-0158 Package Manager Manifest API Redesign

> * What is your evaluation of the proposal? I like the way this provides more harmonisation with Swift coding style. Future extensibility seems to be well provided for. > * Is the problem being addressed significant enough to warrant a change to > the Swift Package Manager? If it were the onl