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

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

> 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 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 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] [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] 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] [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] [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] [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] [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] [Draft] open and public protocols

Sent from my iPad > On Feb 19, 2017, at 9:57 PM, Xiaodi Wu via swift-evolution > wrote: > > Left unsaid from my reply about enums is that implicit conversions should > absolutely be added. We already have this magic for one particular enum, > Optional. +1. I

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

Sent from my iPad On Feb 19, 2017, at 6:30 PM, Brent Royal-Gordon wrote: >> On Feb 19, 2017, at 6:45 AM, Matthew Johnson wrote: >> >> 1. Swift *already* acknowledges that it is far easier to create a reference >> cycle through captured strong

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

Sent from my iPad > On Feb 19, 2017, at 6:52 PM, Daniel Duan <dan...@duan.org> wrote: > > >>> On Feb 19, 2017, at 11:49 AM, Matthew Johnson via swift-evolution >>> <swift-evolution@swift.org> wrote: >>> >>> >>> On Feb 18

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

Sent from my iPad > On Feb 19, 2017, at 5:52 PM, Tony Arnold via swift-evolution > wrote: > > >> On 20 Feb 2017, at 06:25, Jose Cheyo Jimenez via swift-evolution >> wrote: >> >> We need more examples to make this case. > > How do we

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

I want to thank everyone who commented on the first draft of this proposal. I continue to believe the basic idea is a good one but there were a number of problems with the details of the design presented in that draft. They key insight that led to this new design is the idea of using a sigil

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] [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] [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] [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] [Draft] open and public protocols

Sent from my iPad > On Feb 19, 2017, at 10:39 AM, Adrian Zubarev > wrote: > > Still not what I was asking about. > > Module A contains a single open protocol: open protocol P { func foo() } > Module B contains a single open class that conforms to P: > open

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

public/SDK/Foundation/NSError.swift:564 >> _ErrorCodeProtocol >> >> >> >> -- >> Adrian Zubarev >> Sent with Airmail >> >> Am 19. Februar 2017 um 07:59:45, David Waite via swift-evolution >> (swift-evolution@swift.org) schrieb:

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

Sent from my iPad > On Feb 19, 2017, at 11:34 AM, Brandon Knope via swift-evolution > wrote: > > I really like this. Seems much more elegant and simple this way +1 > >> On Feb 17, 2017, at 4:45 PM, Joe Groff via swift-evolution >>

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

Sent from my iPhone > On Feb 19, 2017, at 10:28 AM, Adrian Zubarev > wrote: > > I really feel I’m blind, I cannot find it. Is the access modifier of open > protocol *members* on open/public classes public by default, or open? > > If open, can we downgrade

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

Sent from my iPhone > On Feb 19, 2017, at 10:11 AM, Adrian Zubarev > wrote: > > @Matthew: Have you considered what happens with the access modifier of an > open protocol when an open/public class conforms to it? > Yes I covered this in the detailed design

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

gt;> >>> Assuming you aren’t switching on the implementing type of a protocol (which >>> itself can be a sign that your design isn’t properly using polymorphism), >>> one could get this design by creating a struct with the interface desired, >>> and

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

Sent from my iPad > On Feb 19, 2017, at 7:55 AM, David Hart via swift-evolution > wrote: > > > >> On 19 Feb 2017, at 10:20, Goffredo Marocchi via swift-evolution >> wrote: >> >> The current private is closer to other languages than

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

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

Re: [swift-evolution] [Pre-Proposal] Type Aliases as Pseudo-Types

> On Feb 18, 2017, at 3:16 PM, Haravikk wrote: > > >> On 18 Feb 2017, at 16:28, Matthew Johnson > > wrote: >> >>> >>> On Feb 18, 2017, at 4:54 AM, Brent Royal-Gordon via swift-evolution >>>

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

> On Feb 18, 2017, at 3:01 PM, David Sweeris <daveswee...@mac.com> wrote: > > >> On Feb 18, 2017, at 12:41 PM, Matthew Johnson via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> ## Source compatibility >> >> This propo

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

> On Feb 18, 2017, at 2:55 PM, Daniel Duan <dan...@duan.org> wrote: > >> >> On Feb 18, 2017, at 8:47 AM, Matthew Johnson via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> >>>

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

Now that we’re in phase 2 I’d like to officially propose we introduce `open` protocols and require conformances to `public` protocols be inside the declaring module. Let’s use this thread for feedback on the official proposal. After a healthy round of discussion I’ll open a PR to submit it

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

When writing unit tests sometimes it is necessary to artificially elevate a member to `internal` in order to make it visible to unit tests where it could otherwise be `private` or `fileprivate`. We could introduce an `@testable` attribute that could be applied anywhere an access modifier is

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

> • What is your evaluation of the proposal? +1. I am extremely confident that this is the right direction to go in. I really like Brent’s idea for allowing us to distinguish the parameter label from what he calls the “internal name”. In the value subtyping manifesto I recently

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

Thank you for taking the time to put this proposal together Anton! I really want to see typed throws make it into Swift 4. This will be a very nice feature to have. I noticed that you included Joe Groff’s idea of replacing `rethrows` by making every function have an error type which is by

Re: [swift-evolution] [Pre-Proposal] Type Aliases as Pseudo-Types

> On Feb 18, 2017, at 4:54 AM, Brent Royal-Gordon via swift-evolution > wrote: > >> On Feb 18, 2017, at 2:18 AM, Haravikk via swift-evolution >> wrote: >> >> This is an idea I had while working with collections, and is particularly >>

Re: [swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

> > • What is your evaluation of the proposal? +1. Very nice! > • 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? Very much so. > • If you have used other

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

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

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

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] 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] 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] [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] Typed throws

> On Feb 17, 2017, at 1:42 PM, Adrian Zubarev via swift-evolution > wrote: > > So the typed throws are going to be limited to a single error type, is that > the direction we're heading to? Yes, this topic was discussed thoroughly last year. > > -- > Adrian

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] [Pitch] Support for pure functions. Part n + 1.

has to have a return value. Sent from my iPad > On Feb 17, 2017, at 10:59 AM, Matthew Johnson via swift-evolution > <swift-evolution@swift.org> wrote: > > How do you suggest a closure indicate its purity? Something like this? > > { pure in $0.property } > &

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

word, for improved readability, just before the function > declaration: > > Ex: > > pure func(a:Some) -> Else {} > > > > On Feb 17, 2017, 11:51 AM -0500, Matthew Johnson via swift-evolution > <swift-evolution@swift.org>, wrote: >> >>> On

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

> On Feb 17, 2017, at 10:55 AM, David Sweeris wrote: > > > On Feb 17, 2017, at 08:49, Matthew Johnson > wrote: > >> >>> On Feb 17, 2017, at 10:46 AM, David Sweeris via swift-evolution >>>

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

> On Feb 17, 2017, at 10:46 AM, David Sweeris via swift-evolution > wrote: > > > On Feb 17, 2017, at 08:21, Adrian Zubarev via swift-evolution > > wrote: > >> I haven’t yet read all the feedback in this

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

urity when the provided closure is pure. > > > > -- > Adrian Zubarev > Sent with Airmail > > Am 17. Februar 2017 um 15:37:15, Matthew Johnson via swift-evolution > (swift-evolution@swift.org <mailto:swift-evolution@swift.org>) schrieb: > >> Also,

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] Support for pure functions. Part n + 1.

> On Feb 16, 2017, at 3:18 PM, T.J. Usiyan via swift-evolution > wrote: > > I am ok with a keyword but `pure` in front of func doesn't work well with > inline closures. The `=>` function arrow syntax is a clever way to avoid making pure functions heaver

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

+1. I have always thought this sugar should be consistent throughout the language. > On Feb 17, 2017, at 2:20 AM, Adrian Zubarev via swift-evolution > wrote: > > I’d like to revive an additive proposal that couldn’t make it into Swift 3. > This proposal has a

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

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

I have been thinking a lot about enums and value subtyping lately and decided to write down the ideas I’ve been thinking about. The result is a manifesto-style document that explores a broad landscape of features that could eventually lead to proposals (at the right time, of course). I’m

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

> On Feb 16, 2017, at 3:25 PM, Sean Heber via swift-evolution > wrote: > > Couldn’t pure functions be discovered by the compiler like how the compiler > already discovers an escaping vs. non-escaping function? Then perhaps pure > only needs to be an attribute on

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On Feb 16, 2017, at 8:21 AM, James Froggatt via swift-evolution > wrote: > > >> On 16 Feb 2017, at 02:13, Jordan Rose wrote: >> >> >>> On Feb 13, 2017, at 09:28, James Froggatt via swift-evolution >>> wrote:

Re: [swift-evolution] [Pitch] consistent public access modifiers (value subtyping digression)

Sent from my iPad > On Feb 15, 2017, at 8:17 PM, Jordan Rose <jordan_r...@apple.com> wrote: > > >>> On Feb 13, 2017, at 09:33, Matthew Johnson via swift-evolution >>> <swift-evolution@swift.org> wrote: >>> >>> >>> On Feb 13,

Re: [swift-evolution] [Pitch] consistent public access modifiers (value subtyping digression)

Sent from my iPad > On Feb 15, 2017, at 8:17 PM, Jordan Rose <jordan_r...@apple.com> wrote: > > >>> On Feb 13, 2017, at 09:33, Matthew Johnson via swift-evolution >>> <swift-evolution@swift.org> wrote: >>> >>> >>> On Feb 13,

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

> On Feb 15, 2017, at 4:16 PM, David Hart wrote: > > >> On 15 Feb 2017, at 23:15, Matthew Johnson > > wrote: >> >>> >>> On Feb 15, 2017, at 4:12 PM, David Hart >> >

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

> On Feb 15, 2017, at 4:12 PM, David Hart wrote: > >> >> On 15 Feb 2017, at 16:31, Matthew Johnson > > wrote: >> >> >>> On Feb 14, 2017, at 11:31 PM, Chris Lattner via swift-evolution >>>

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On Feb 14, 2017, at 3:43 AM, Brent Royal-Gordon > wrote: > >> On Feb 13, 2017, at 7:45 AM, Matthew Johnson wrote: >> >> If you look closely, when most people say “closed enum” they mean a fixed, >> complete set of cases that are all public.

Re: [swift-evolution] [Pitch] consistent public access modifiers

;>> >>>> >>>> On 15 Feb 2017, at 16:45, Matthew Johnson <matt...@anandabits.com> wrote: >>>> >>>>> >>>>> On Feb 15, 2017, at 9:35 AM, Rien <r...@balancingrock.nl> wrote: >>>>> >>>>> &g

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On Feb 15, 2017, at 9:59 AM, Rien <r...@balancingrock.nl> wrote: > >> >> On 15 Feb 2017, at 16:45, Matthew Johnson <matt...@anandabits.com> wrote: >> >>> >>> On Feb 15, 2017, at 9:35 AM, Rien <r...@balancingrock.nl> wrote: >&g

Re: [swift-evolution] Rules for structs default/memberwise initializers

Hi Dimitri, You may be interested in taking a look at a proposal I introduced about a year ago which was deferred. Memberwise initialization is a topic we intend to revisit eventually. This may happen in phase 2 of the Swift 4 effort, or may not happen until Swift 5.

Re: [swift-evolution] Simplifying Access Using 'Hidden'

> On Feb 15, 2017, at 9:37 AM, Michel Fortin via swift-evolution > wrote: > > >> Le 15 févr. 2017 à 9:28, Vladimir.S via swift-evolution >> a écrit : >> >> On 15.02.2017 14:29, Joanna Carter via swift-evolution wrote: The beauty of

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On Feb 15, 2017, at 9:35 AM, Rien <r...@balancingrock.nl> wrote: > > >> On 15 Feb 2017, at 16:11, Matthew Johnson via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> >>> On Feb 15, 2017, at 5:59 AM, Jeremy Pereira via

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

> On Feb 14, 2017, at 11:31 PM, Chris Lattner via swift-evolution > wrote: > > >> On Feb 14, 2017, at 3:20 AM, David Hart > > wrote: >> >> >> On 14 Feb 2017, at 09:25, Goffredo Marocchi >

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On Feb 15, 2017, at 5:59 AM, Jeremy Pereira via swift-evolution > wrote: > > >> On 15 Feb 2017, at 11:11, Brent Royal-Gordon via swift-evolution >> wrote: >> >> >> Our philosophy in general, however, is to default to the behavior

Re: [swift-evolution] [Pitch] consistent public access modifiers

in every case?) > but it’s unlikely that the client is going to be testing those enumerations > in a switch statement anyway. In order to support adding cases to enums meant to be passed in to a library we have to introduce some kind of syntax to distinguish these enums from enums that are

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On Feb 15, 2017, at 5:11 AM, Brent Royal-Gordon > wrote: > >> On Feb 14, 2017, at 6:16 PM, Xiaodi Wu wrote: >> >> So, perhaps I'm being simplistic here, but-- >> >> At the end of the day, aren't we simply trying to enable a resiliency >>

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On Feb 14, 2017, at 3:43 AM, Brent Royal-Gordon > wrote: > >> On Feb 13, 2017, at 7:45 AM, Matthew Johnson wrote: >> >> If you look closely, when most people say “closed enum” they mean a fixed, >> complete set of cases that are all public.

Re: [swift-evolution] Class and Subclass Existentials (Round 2)

ler<UITableViewDataSource,UITableViewDelegate>*)tableViewController; >>> @end >>> is imported into Swift-3 mode as: >>> >>> class MyViewController { >>> func setup(tableViewController: UIViewController) {} >>> } >>> which allows calling

Re: [swift-evolution] Class and Subclass Existentials (Round 2)

cause Objective-C >>>> types will continue to be imported as before. But in Swift 4 mode, all >>>> types bridged from Objective-C which use the equivalent Objective-C >>>> existential syntax could break code which does not meet the new protocol >>>> require

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

> On Feb 13, 2017, at 12:40 PM, Zach Waldowski via swift-evolution > wrote: > > I still haven't been convinced by this. What are these incredibly large files > that people are dealing with, and why should a crucial feature of the > language be built around

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On Feb 13, 2017, at 11:28 AM, James Froggatt via swift-evolution > wrote: > > Having loosely followed this discussion, the way I'm thinking of ‘closed’ is > as a modifier which would let you switch over something from outside the > module in which it is declared.

<    1   2   3   4   5   6   7   8   9   10   >