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

Sent from my iPad > On Feb 21, 2017, at 5:45 AM, David Hart via swift-evolution > wrote: > > >>> On 21 Feb 2017, at 11:40, Brent Royal-Gordon wrote: >>> >>> On Feb 20, 2017, at 10:58 PM, David Hart via swift-evolution >>>

Re: [swift-evolution] [Pitch] Let's talk about submodules

Sent from my iPad On Feb 21, 2017, at 4:01 AM, Brent Royal-Gordon wrote: >> On Feb 20, 2017, at 7:59 PM, Matthew Johnson wrote: >> >>> Any group of Swift files can be grouped together to form a submodule. >> >> It isn't clear to me how you

Re: [swift-evolution] [Pitch] Let's talk about submodules

Sent from my iPad On Feb 21, 2017, at 5:18 AM, Dimitri Racordon wrote: >> Maybe we should try to collect what people want from submodules first. > > I’d like a simple method to group my sources files into some kind lexical > scope. Nothing more actually =D I

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

> On Feb 21, 2017, at 10:29 PM, Robert Widmann wrote: > > This level of access, the “private to this submodule except to the select set > of interfaces I want to see it” level, is the equivalent of friend classes in > C++. I don’t consider leaving this out to be a

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

> On Feb 21, 2017, at 10:25 PM, Robert Widmann wrote: > > Good question! This behavior is actually the behavior that exists today. > For example, open a playground and type > > import Foundation.NSDebug > > let s : NSString = “" > > You’ll notice no matter which

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

> On Feb 21, 2017, at 9:38 PM, Michel Fortin wrote: > >> Le 21 févr. 2017 à 22:05, Matthew Johnson a écrit : >> Le 20 févr. 2017 à 12:17, Matthew Johnson a écrit : > e) Generic Containers: >

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

> On Feb 21, 2017, at 10:11 PM, Matthew Johnson wrote: > > >> On Feb 21, 2017, at 9:47 PM, Brent Royal-Gordon via swift-evolution >> wrote: >> >>> On Feb 21, 2017, at 7:38 PM, Robert Widmann >>> wrote: >>> >>>

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

> On Feb 20, 2017, at 7:56 PM, Robert Widmann via swift-evolution > wrote: > > Good Evening All, > > Jaden Geller and I have been considering a (sub)module system for Swift that > would complement the existing language but also provide sorely needed > modularity.

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

> On Feb 21, 2017, at 9:42 PM, Robert Widmann wrote: > > >> On Feb 21, 2017, at 10:36 PM, Matthew Johnson > > wrote: >> >>> >>> On Feb 21, 2017, at 9:28 PM, Robert Widmann via swift-evolution >>>

Re: [swift-evolution] [Pitch] Let's talk about submodules

> On Feb 20, 2017, at 7:36 PM, Brent Royal-Gordon via swift-evolution > wrote: > > Okay, lots of people want to have some kind of submodule feature, so I'd like > to sketch one out so we can hopefully agree on what submodules might look > like. > > *** > > Any

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

> On Feb 21, 2017, at 8:57 PM, Michel Fortin via swift-evolution > wrote: > > (this was accidentally sent off-list, reposting here a day later) And this was my reply. > >> Le 20 févr. 2017 à 12:17, Matthew Johnson a écrit : >> >>> e)

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

> On Feb 21, 2017, at 9:28 PM, Robert Widmann via swift-evolution > wrote: > >> >> On Feb 21, 2017, at 10:03 PM, Xiaodi Wu > > wrote: >> >> On Tue, Feb 21, 2017 at 8:41 PM, Robert Widmann

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

> On Feb 21, 2017, at 9:47 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> On Feb 21, 2017, at 7:38 PM, Robert Widmann wrote: >> >> Correct. Because, in dividing the submodule across an extension, you have >> placed what should

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

Sent from my iPad > On Feb 21, 2017, at 11:09 PM, Robert Widmann wrote: > > >>> On Feb 21, 2017, at 11:59 PM, Matthew Johnson >>> wrote: >>> >>> >>> On Feb 21, 2017, at 10:41 PM, Robert Widmann >>> wrote: >>>

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

> On Feb 21, 2017, at 10:41 PM, Robert Widmann wrote: > > By API boundaries I mean both the one internal to MyModule.Foo and the one > defined by MyModule. Here “the API boundary” is explicitly about the > submodule MyModule.Foo, whose internal state may have been

Re: [swift-evolution] [Pitch] Let's talk about submodules

> On Feb 22, 2017, at 2:04 AM, Brent Royal-Gordon via swift-evolution > wrote: > >> On Feb 21, 2017, at 11:11 PM, Jonathan Hull via swift-evolution >> wrote: >> >> There is one major use case which I see all of these proposals failing to

Re: [swift-evolution] Treating an Enum's Cases as Its Subtypes

It isn’t clear to me whether or not the core team views this as something they are willing to consider for Swift 4 or not, but it is definitely not in the realm of syntactic sugar so it has a better chance than `asCase?`. Joe, any thoughts on whether it’s worth investing time into a proposal or

Re: [swift-evolution] [Proposal] Typed throws

> On Feb 22, 2017, at 7:10 AM, Anton Zhilin wrote: > > How about this: > > func bypassRethrows(_ f: () throws(E) -> ()) throws(E) { > if let e = (MyError() as Error) as? E { > throw e > } > } > I obviously can’t “test” this right now, but should work? >

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

> On Feb 22, 2017, at 12:32 AM, David Hart wrote: > > >> On 21 Feb 2017, at 23:41, Xiaodi Wu > > wrote: >> >> Well-written as-is. >> >> Overall, my feedback is that solution 2 should not be on the table (though >> there

Re: [swift-evolution] [Draft] Guarded closures and `@guarded` arguments

> On Feb 19, 2017, at 11:35 PM, Brent Royal-Gordon <br...@architechies.com> > wrote: > >> On Feb 19, 2017, at 2:57 PM, Matthew Johnson via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> A guarded closure may be created by pr

Re: [swift-evolution] final + lazy + fileprivate modifiers

> On Feb 20, 2017, at 5:43 AM, Ross O'Brien via swift-evolution > wrote: > > My two cents: > > I like that Swift has a way of restricting access to some properties and > functions to just the scope in which they're declared (Swift 3 private). > > At the moment I

Re: [swift-evolution] final + lazy + fileprivate modifiers

> On Feb 20, 2017, at 12:31 AM, David Hart via swift-evolution > wrote: > > > >> On 20 Feb 2017, at 00:52, Tony Arnold via swift-evolution >> wrote: >> >> >>> On 20 Feb 2017, at 06:25, Jose Cheyo Jimenez via swift-evolution >>>

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

> On Feb 20, 2017, at 10:24 AM, Michel Fortin via swift-evolution > wrote: > > Le 20 févr. 2017 à 1:19, David Sweeris a écrit : >> >> On Feb 19, 2017, at 21:19, Xiaodi Wu wrote: >> >>> This is very, very interesting.

Re: [swift-evolution] [Draft] Guarded closures and `@guarded` arguments

> On Feb 20, 2017, at 8:33 AM, Florent Bruneau <florent.brun...@intersec.com> > wrote: > > > >> Le 20 févr. 2017 à 06:35, Brent Royal-Gordon via swift-evolution >> <swift-evolution@swift.org> a écrit : >> >>> On Feb 19, 2017, at 2:

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

> On Feb 20, 2017, at 10:55 AM, Michel Fortin via swift-evolution > wrote: > > (continuing my thoughts from my previous post) > > I think a definition of `pure` that'd work well for Swift is one that is > based on forbidding dereferencing of pointers (including

Re: [swift-evolution] A compiler option to warn if a closure captures a strong reference to a class instance?

> On Feb 20, 2017, at 11:09 AM, David Hart via swift-evolution > wrote: > > >> On 20 Feb 2017, at 12:22, Lauri Lehmijoki via swift-evolution >> > wrote: >> >> I'm developing an application where we use

Re: [swift-evolution] [Manifesto] Ownership

> On Feb 20, 2017, at 2:40 AM, Florent Bruneau via swift-evolution > wrote: > > Hi John, > > I've spent 3 hours reading the manifesto and its really very interesting. > Despite the completeness of the included discussion, I have a few > comments/concerns. > > >

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

> On Feb 20, 2017, at 1:42 PM, Michel Fortin wrote: > >> Le 20 févr. 2017 à 14:23, Charles Srstka a écrit : >> >> I’m not sure how I feel about that, since it hamstrings the ability to >> improve APIs in a lot of ways without breaking

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

> On Feb 20, 2017, at 12:42 PM, Charles Srstka via swift-evolution > wrote: > >> On Feb 20, 2017, at 10:55 AM, Michel Fortin via swift-evolution >> > wrote: >> >> a) Structs/Locals: >> Structs and local

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

> On Feb 20, 2017, at 1:23 PM, Charles Srstka wrote: > >> On Feb 20, 2017, at 12:53 PM, Matthew Johnson > > wrote: >> >>> >>> On Feb 20, 2017, at 12:42 PM, Charles Srstka via swift-evolution >>>

Re: [swift-evolution] [Draft] open and public protocols

: >>> >>> >>>> On Feb 18, 2017, at 12:41 PM, Matthew Johnson via swift-evolution >>>> <swift-evolution@swift.org> wrote: >>>> >>>> ## Source compatibility >>>> >>>> This proposal breaks source co

Re: [swift-evolution] [Draft] open and public protocols

> On Feb 18, 2017, at 3:43 PM, Charles Srstka <cocoa...@charlessoft.com> wrote: > >> On Feb 18, 2017, at 2:41 PM, Matthew Johnson via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> There are go

[swift-evolution] [Draft] @selfsafe: a new way to avoid reference cycles

# `@selfsafe`: a new way to avoid reference cycles * Proposal: [SE-](-selfsafe.md) * Authors: [Matthew Johnson](https://github.com/anandabits) * Review Manager: TBD * Status: **Awaiting review** ## Introduction This proposal introduces the `@selfsafe` function argument attribute which

Re: [swift-evolution] [Proposal] Typed throws

ht on this. It’s possible this would be a necessary bridge solution until we have something more permanent as I described above. > 2017-02-19 0:16 GMT+03:00 Martin Waitz <t...@admingilde.org > <mailto:t...@admingilde.org>>: > > > > >> Am 18.02.2017 um 17:37 sc

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

> On Feb 19, 2017, at 1:47 PM, Michel Fortin via swift-evolution > wrote: > > I'm a bit disappointed to see this discussion bikeshedding the syntax without > clarifying much the semantics. Here's a few question of semantic nature. +1. I think the syntactic

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

> On Feb 18, 2017, at 10:49 PM, Dave Abrahams via swift-evolution > > wrote: > > I'm on vacation and don't have time for a full review right now, but I am > concerned that wild this proposal would make enums more general and uniform

Re: [swift-evolution] [Proposal] Typed throws

> On Feb 19, 2017, at 2:16 PM, Anton Zhilin wrote: > > 2017-02-19 22:59 GMT+03:00 Matthew Johnson >: > > > >> On Feb 19, 2017, at 1:32 PM, Anton Zhilin >

Re: [swift-evolution] [Proposal] Typed throws

> On Feb 20, 2017, at 11:14 AM, Anton Zhilin wrote: > > 2017-02-20 18:23 GMT+03:00 Matthew Johnson >: > > > > >> On Feb 20, 2017, at 3:58 AM, Anton Zhilin >

Re: [swift-evolution] [Manifesto] Ownership

> On Feb 20, 2017, at 3:38 PM, John McCall wrote: > >> On Feb 20, 2017, at 4:26 PM, Matthew Johnson > > wrote: >>> On Feb 19, 2017, at 11:24 PM, John McCall >> > wrote:

Re: [swift-evolution] Treating an Enum's Cases as Its Subtypes

> On Feb 20, 2017, at 2:38 PM, Joe Groff <jgr...@apple.com> wrote: > >> >> On Feb 20, 2017, at 7:32 AM, Matthew Johnson via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >>> >>>

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

> On Feb 20, 2017, at 4:50 PM, Michel Fortin > wrote: > >> Le 20 févr. 2017 à 14:45, Matthew Johnson > > a écrit : >> >>> >>> On Feb 20, 2017, at 1:42 PM, Michel Fortin

Re: [swift-evolution] [Manifesto] Ownership

> On Feb 19, 2017, at 11:24 PM, John McCall wrote: > >> On Feb 18, 2017, at 11:08 AM, Matthew Johnson > > wrote: >> Hi John, >> >> This is fantastic! I’ve been eagerly anticipating this. It looks very much >> as I

Re: [swift-evolution] Treating an Enum's Cases as Its Subtypes

Joe Groff <jgr...@apple.com >>> <mailto:jgr...@apple.com>> wrote: >>> >>>> >>>> On Feb 20, 2017, at 7:32 AM, Matthew Johnson via swift-evolution >>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>

Re: [swift-evolution] [Draft] @selfsafe: a new way to avoid reference cycles

to use an API incorrectly they would get a compiler error. > > On 19 Feb 2017, at 09:15, Brent Royal-Gordon via swift-evolution > <swift-evolution@swift.org> wrote: > >>> On Feb 18, 2017, at 5:24 PM, Matthew Johnson via swift-evolution >>> <swift-evol

Re: [swift-evolution] [Pitch] @testable private members

Sent from my iPad On Feb 19, 2017, at 12:21 AM, Brent Royal-Gordon <br...@architechies.com> wrote: >> On Feb 18, 2017, at 10:14 AM, Matthew Johnson via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> When writing unit tests sometimes it

Re: [swift-evolution] [Pitch] @testable private members

our code a lot cleaner. > > ~Robert Widmann > >> On Feb 18, 2017, at 1:14 PM, Matthew Johnson via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> When writing unit tests sometimes it is necessary to artificially elevate a >> member t

Re: [swift-evolution] [Draft] @selfsafe: a new way to avoid reference cycles

Sent from my iPad On Feb 19, 2017, at 2:15 AM, Brent Royal-Gordon <br...@architechies.com> wrote: >> On Feb 18, 2017, at 5:24 PM, Matthew Johnson via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> This proposal introduces the `@selfsaf

Re: [swift-evolution] [Draft] @selfsafe: a new way to avoid reference cycles

>> <swift-evolution@swift.org> wrote: >> This reminded me of an idea I had long time ago which will have a similar >> effect: add a way to disable implicit captures for closures. FWIW. >> >> > On Feb 18, 2017, at 5:24 PM, Matthew Johnson

Re: [swift-evolution] [Draft] open and public protocols

isn’t properly using polymorphism), one > could get this design by creating a struct with the interface desired, and > passing invocations through to an internal protocol reference. > > -DW > >> On Feb 18, 2017, at 1:41 PM, Matthew Johnson via swift-evolution >> &

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

> On Feb 20, 2017, at 6:54 PM, Michel Fortin wrote: > >> >> Le 20 févr. 2017 à 18:02, Matthew Johnson a écrit : >> >> >>> On Feb 20, 2017, at 4:50 PM, Michel Fortin wrote: >>> Le 20 févr. 2017 à 14:45,

Re: [swift-evolution] [Pitch] Let's talk about submodules

Sent from my iPad > On Feb 20, 2017, at 7:36 PM, Brent Royal-Gordon via swift-evolution > wrote: > > Okay, lots of people want to have some kind of submodule feature, so I'd like > to sketch one out so we can hopefully agree on what submodules might look > like.

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

Thanks for bringing up submodules Robert. I agree it's a good time to discuss them. There seem to be two broad approaches to submodules. One is more of a physical / encapsulation based view and the other is more of a logical / namespace based view. This proposal falls into the latter

Re: [swift-evolution] final + lazy + fileprivate modifiers

> On Feb 17, 2017, at 4:29 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> On Feb 17, 2017, at 12:29 AM, Slava Pestov via swift-evolution >> wrote: >> >> Personally I feel enforced encapsulation of implementation detail to the

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

> On Feb 17, 2017, at 2:52 PM, Jonathan Hull via swift-evolution > wrote: > > Out of curiosity, what are the benefits to being able to define that a > closure must be pure as a parameter/type definition, as opposed to defining a > particular closure to being pure

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

should of course be limited to argument and return types of > pure functions only. I think there might be a possibility of use in > typealias, but need to think more about it. > > On Fri, 17 Feb 2017 at 22:59 Matthew Johnson via swift-evolution > <swift-evolution@swift.org <mailto

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

ine the returned function purity in every place function >> is used. >> >> The use of ~> should of course be limited to argument and return types of >> pure functions only. I think there might be a possibility of use in >> typealias, but need to think more abo

Re: [swift-evolution] [Pitch] Typed throws

> On Feb 17, 2017, at 3:45 PM, Joe Groff via swift-evolution > wrote: > > >> On Feb 17, 2017, at 11:03 AM, Adrian Zubarev via swift-evolution >> > wrote: >> >> I suggest we need to find a way to shorten

Re: [swift-evolution] [Proposal] [Stage–2] `return` consistency for single-expressions

> On Feb 17, 2017, at 8:41 AM, Vladimir.S via swift-evolution > wrote: > > I think I like this, but what about guard? > > func f(x: Int) -> Int { > guard x > 0 else { return 0 } > ... > } > > vs > > func f(x: Int) -> Int { > guard x > 0 else { 0 } > …

Re: [swift-evolution] [Pitch] Typed throws

> On Feb 17, 2017, at 1:24 PM, Xiaodi Wu via swift-evolution > wrote: > > Let's not bring bikeshedding the commonly proposed and rejected union > spelling into this. > Typed throws would be a nice addition, assuming that the core team finds it > in scope for phase

Re: [swift-evolution] final + lazy + fileprivate modifiers

Sent from my iPad > On Feb 16, 2017, at 8:36 PM, David Sweeris via swift-evolution > wrote: > > >> On Feb 16, 2017, at 14:34, Slava Pestov via swift-evolution >> wrote: >> >> While we’re bikeshedding, I’m going to add my two cents.

Re: [swift-evolution] Value Subtypes and Generalized Enums, a manifesto

<razie...@gmail.com> wrote: >>>> >>>> >>>>> On 17 Feb 2017, at 00:00, Karl Wagner <karl.sw...@springsup.com> wrote: >>>>> >>>>> >>>>> On 16 Feb 2017, at 23:44, Matthew Johnson via swift-evolution >&g

Re: [swift-evolution] Value Subtypes and Generalized Enums, a manifesto

> On Feb 16, 2017, at 5:13 PM, Karl Wagner <razie...@gmail.com> wrote: > > >> On 17 Feb 2017, at 00:00, Karl Wagner <karl.sw...@springsup.com >> <mailto:karl.sw...@springsup.com>> wrote: >> >> >>> On 16 Feb 2017, at 23:44, Matthew

Re: [swift-evolution] Value Subtypes and Generalized Enums, a manifesto

> On Feb 16, 2017, at 5:00 PM, Karl Wagner <razie...@gmail.com> wrote: > > >> On 16 Feb 2017, at 23:44, Matthew Johnson via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> I have been th

Re: [swift-evolution] final + lazy + fileprivate modifiers

> On Feb 16, 2017, at 4:55 PM, John McCall via swift-evolution > wrote: > >> On Feb 16, 2017, at 5:42 PM, Sean Heber via swift-evolution >> wrote: >> Honestly I really think this should be seriously considered. I do use >> private and

Re: [swift-evolution] final + lazy + fileprivate modifiers

Sent from my iPad > On Feb 17, 2017, at 6:44 PM, Xiaodi Wu via swift-evolution > wrote: > >> On Fri, Feb 17, 2017 at 5:49 PM, Rob Mayoff via swift-evolution >> wrote: >>> On Fri, Feb 17, 2017 at 3:56 PM, Xiaodi Wu via swift-evolution

Re: [swift-evolution] final + lazy + fileprivate modifiers

ate then make it part of the coding style. > > If people do not want fileprivate because it looks ugly, then force everybody > to use scope private using a linter like swiftlint. > > > > > > > > > > > > > > > > > >

Re: [swift-evolution] final + lazy + fileprivate modifiers

ch `private` and used `local` for scoped access which was a bad name for many reasons. The conversation had always called it "scoped access" informally. I think `scoped` would make a good name for it and find it pretty unfortunate that it wasn't spelled that way in the initial proposa

Re: [swift-evolution] Dictionary Enhancements

Sent from my iPad > On Feb 17, 2017, at 8:50 PM, Jonathan Hull via swift-evolution > wrote: > > Thoughts inline. > >> On Feb 16, 2017, at 4:26 PM, Ben Cohen via swift-evolution >> wrote: >> >> Hi swift-evolution, >> >> Following up

Re: [swift-evolution] [Manifesto] Ownership

Hi John, This is fantastic! I’ve been eagerly anticipating this. It looks very much as I was hoping it would. I can’t wait to see this vision come to life! You only show a mutating generator example. Do you also plan to allow shared generators? One topic you don’t touch on that feels

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0154: Provide Custom Collections for Dictionary Keys and Values

> 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 a similar feature, how do > you

Re: [swift-evolution] Implicit conversion between primitive types

> On Feb 18, 2017, at 7:23 AM, Milos Jakovljevic via swift-evolution > wrote: > > Are there are any plans of adding implicit conversion between primitive types? > > For example > > var float = 5.0 > > func accept(float: Float) { >print("this is \(float)") > }

Re: [swift-evolution] [Proposal] Guarded self in closures

Hi David, I just shared a draft proposal to introduce guarded closures last week: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170213/032478.html . I think you would find it very

Re: [swift-evolution] Pitch: Compound name `foo(:)` for nullary functions

> On Feb 22, 2017, at 12:30 PM, David Sweeris <daveswee...@mac.com> wrote: > > >> On Feb 22, 2017, at 7:48 AM, Matthew Johnson via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> I like this idea. I think you made the right choice of

Re: [swift-evolution] [Proposal] Guarded self in closures

> On Feb 22, 2017, at 3:36 PM, David Hedbor via swift-evolution > wrote: > > I did read it, but I think I skimmed it a bit too fast. You're correct in > that it essentially solves the same problem using a different syntax (more > compact at that). I think when I

Re: [swift-evolution] [Draft] Guarded closures and `@guarded` arguments

is case. The good news is that this would still be valid code within a guarded closure because the new proposal allows you to override the guarded behavior using the capture list. > >> On 20 Feb 2017, at 18:01, Matthew Johnson via swift-evolution >> <swift-evolution@swi

Re: [swift-evolution] Treating an Enum's Cases as Its Subtypes

ities. It isn’t clear to me > whether or not the core team views this as something they are willing to > consider for Swift 4 or not, but it is definitely not in the realm of > syntactic sugar so it has a better chance than `asCase?`. Joe, any thoughts > on whether it’s worth inves

Re: [swift-evolution] [Proposal] Guarded self in closures

> On Feb 22, 2017, at 4:06 PM, David Hedbor wrote: > > One more thing I'd like to add into the discussion is handling of optional > variables. My assumption is that if I have an optional variable in the outer > scope, it would remain optional in the inner scope, but the way

Re: [swift-evolution] [Discussion] Analysis of the design of typed throws

> On Feb 24, 2017, at 12:06 PM, David Hart <da...@hartbit.com> wrote: > > Sending to mailing list: > > On 23 Feb 2017, at 01:37, Matthew Johnson via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > >

Re: [swift-evolution] [Discussion] Analysis of the design of typed throws

r during propagation. >> >>> The thread is really long and I personally was not able to follow it >>> from the beginning(so I believe the answer can be helpful for others >>> like me). Thank you(really). >>> >>> On 23.02.2017 20:09, Matthew Johns

Re: [swift-evolution] [Discussion] Analysis of the design of typed throws

re to catch all types that may thrown in the `do` block. > > And if 'old' syntax (i.e. foo() throws {...}) without specifying list of > exception classes will be allowed? Yes > >> >>> The thread is really long and I personally was not able to follow it >>&

Re: [swift-evolution] Analysis of existing scopes

> On Feb 23, 2017, at 1:34 PM, Joanna Carter > wrote: > > >> Le 23 févr. 2017 à 14:59, Matthew Johnson a écrit : >> >> The rationale for this is that it allows you to explore the eventual design >> of a type without exposing it. When

Re: [swift-evolution] [Discussion] Analysis of the design of typed throws

> On Feb 23, 2017, at 12:30 PM, Anton Zhilin wrote: > > 2017-02-23 21:01 GMT+03:00 Matthew Johnson >: > I don’t understand what you mean here. > > I was a bit confused. Thanks to your clarification, I discovered

[swift-evolution] [Draft] scope-based submodules

I didn't expect submodules to be a part of the Swift 4 discussion. When it came up I was pleasantly surprised. I have been thinking about the design of a submodule system for quite a while but was planning to wait until it was clearly in scope to draft a proposal. Now that the topic has been

Re: [swift-evolution] [Discussion] Analysis of the design of typed throws

g argument. `Either<E, F>` is not a subtype of `E` or `F`. The only way to propagate both errors without resorting to simply specifying `Error` as your error type is to catch them and wrap them (at least until we have a built-in mechanism for implicit error conversions). > > - Karl

Re: [swift-evolution] [Proposal] Guarded self in closures

the scope of the user code in the closure >>>>>> // it is used by libraries to detect when they can safely >>>>>> discard their reference to the closure because it has become a no-op >>>>>> // context is a super secret compiler r

Re: [swift-evolution] [Pitch] Typed throws

> On Feb 24, 2017, at 11:00 AM, Joe Groff via swift-evolution > wrote: > > >> On Feb 23, 2017, at 10:36 PM, Russ Bishop > > wrote: >> >> >>> On Feb 21, 2017, at 8:18 AM, Joe Groff >>

Re: [swift-evolution] Pitch: Compound name `foo(:)` for nullary functions

> On Feb 23, 2017, at 12:52 PM, Anton Zhilin via swift-evolution > wrote: > > +1 to foo(:) version. > I can easily see placeholder arguments as a sugary syntax for closures: > This shorthand has been explicitly rejected several times in favor of the $ argument

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

ot intended for _ to be an ordinary identifier, but as a way of >>>> spelling the empty case name. Ambiguous cases, not distinguished by either >>>> full name or payload type, would be errors. How to construct anonymous >>>> cases? I guess it would be MyEnum

Re: [swift-evolution] A Comprehensive Rethink of Access Levels in Swift

Sent from my iPad > On Feb 25, 2017, at 12:12 AM, David Waite via swift-evolution > wrote: > >>> On Feb 23, 2017, at 2:56 PM, Nevin Brackett-Rozinsky via swift-evolution >>> wrote: >> > >> >> The prevailing view from recent

Re: [swift-evolution] [Draft] scope-based submodules

e the file as-is because those ancestors would not exist in the context you placed it in your module (unless you want to be evil and couple your module structure to that of a copy-and-paste dependency). > > > On 24.02.2017 22:34, Matthew Johnson via swift-evolution wrote: >> I didn't expect

Re: [swift-evolution] [Draft] scope-based submodules

> On Feb 24, 2017, at 4:57 PM, David Hart <da...@hartbit.com> wrote: > >> >> On 24 Feb 2017, at 20:34, Matthew Johnson via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> I didn't expect su

Re: [swift-evolution] A Comprehensive Rethink of Access Levels in Swift

Sent from my iPad > On Feb 25, 2017, at 2:54 PM, Jonathan Hull via swift-evolution > wrote: > > +1000 > > This is the best of the proposals I have seen. I think it works by itself as > a complete proposal, but since we are talking "comprehensive rethink", there

Re: [swift-evolution] A Comprehensive Rethink of Access Levels in Swift

> On Feb 25, 2017, at 3:27 PM, Kevin Nattinger via swift-evolution > wrote: > >> … >> Additionally, the design allows ‘final’ to take any one of those visibility >> levels as a parameter, to indicate that the type should be treated as >> ‘final’ at and above the

Re: [swift-evolution] A Comprehensive Rethink of Access Levels in Swift

> On Feb 25, 2017, at 4:01 PM, Jonathan Hull wrote: > >> >> On Feb 25, 2017, at 1:19 PM, Matthew Johnson > > wrote: >>> On Feb 25, 2017, at 2:54 PM, Jonathan Hull via swift-evolution >>>

Re: [swift-evolution] Analysis of existing scopes

> On Feb 23, 2017, at 4:47 AM, Joanna Carter via swift-evolution > wrote: > > And now I find, what I consider to be, a very peculiar anomaly in method > visibility. > > private class PrivateBaseClass > { > internal func internalFunc() { } > > public func

Re: [swift-evolution] [Proposal] Guarded self in closures

>>>>>> closure is a strong reference. I wouldn't want `DispatchQueue.async` to >>>>>> take a guarded closure. That API doesn’t contain any semantic content >>>>>> around *why* you dispatched async. It’s not a callback, but instead a >>&

[swift-evolution] [Discussion] Analysis of the design of typed throws

# Analysis of the design of typed throws ## Problem There is a problem with how the proposal specifies `rethrows` for functions that take more than one throwing function. The proposal says that the rethrown type must be a common supertype of the type thrown by all of the functions it

Re: [swift-evolution] [Proposal] Guarded self in closures

nce. But it gives an opportunity to do things without explicit weak > references just as guarded closures do. It also adds an ability to avoid an > execution of pure (or just not bound to context) operations you depends on. > Deallocation of context will lead to cancellation of full chain

Re: [swift-evolution] [Proposal] Guarded self in closures

It nudges them not to by offering to thread the context but it doesn’t do anything to prevent it. You can still create a strong reference (event to self) without specifying it in the capture list. I think there is a place for a language solution here. > >> On Feb 22, 2017, at 22:57,

Re: [swift-evolution] [Proposal] Guarded self in closures

> On Feb 22, 2017, at 4:57 PM, David Hedbor wrote: > > > > > On Wed, Feb 22, 2017 at 2:23 PM, Matthew Johnson > wrote: > >> On Feb 22, 2017, at 4:06 PM, David Hedbor >

<    4   5   6   7   8   9   10   11   12   13   >