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

Sent from my iPad > On Feb 22, 2017, at 5:28 PM, David Hedbor wrote: > > > >> On Wed, Feb 22, 2017 at 3:09 PM, Matthew Johnson >> wrote: >> >>> On Feb 22, 2017, at 4:57 PM, David Hedbor wrote: >>> >>> >>> >>> On Wed,

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

using a sum type. // In that case we might have an error type such as Either<AnUninhabitableType, AnotherUninhabitableType>. // Because all cases of the sum type have an associated value with an uninhabitable the sum type is as well. try rethrower(f: nothrow, g: ithrow) > On Feb 22, 2017, at 6:3

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

> On Feb 23, 2017, at 11:41 AM, Anton Zhilin wrote: > > 2017-02-23 20:09 GMT+03:00 Matthew Johnson >: > >> On Feb 23, 2017, at 10:58 AM, Anton Zhilin > >

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

er can be helpful for others like me). > Thank you(really). > > On 23.02.2017 20:09, Matthew Johnson via swift-evolution wrote: >> >>> On Feb 23, 2017, at 10:58 AM, Anton Zhilin <antonyzhi...@gmail.com >>> <mailto:antonyzhi...@gmail.com>> wrote: &g

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

problem with that at all. As I point out in the analysis below, rethrowing functions are allowed to throw any error they want. They are only limited by *where* they may throw. > > 2017-02-23 3:37 GMT+03:00 Matthew Johnson via swift-evolution > <swift-evolution@swift.org <ma

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

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

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

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

[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

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

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

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

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

[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] [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] [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] [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] Treating an Enum's Cases as Its Subtypes

> On Feb 21, 2017, at 2:35 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote: > > On Tue, Feb 21, 2017 at 6:56 AM, Matthew Johnson via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > > > Sent from my iPad > > O

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

Sent from my iPad On Feb 21, 2017, at 4:40 AM, Brent Royal-Gordon via swift-evolution wrote: >> On Feb 20, 2017, at 10:58 PM, David Hart via swift-evolution >> wrote: >> >> The scoped keyword is a good choice not only because the

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

Sent from my iPhone On Feb 21, 2017, at 9:18 AM, Brent Royal-Gordon wrote: >> On Feb 21, 2017, at 5:36 AM, Matthew Johnson wrote: >> >> This is true for lexical scoping, but I'd also like to see scoped be >> parameterized to take the name of

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

Sent from my iPhone > On Feb 20, 2017, at 5:51 PM, Anton Zhilin wrote: > > 2017-02-21 1:21 GMT+03:00 Matthew Johnson : >> >> Thanks for the links. I scanned through them somewhat quickly and didn’t >> see anything that specifically said

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] Let's talk about submodules

> On Feb 22, 2017, at 1:31 AM, Brent Royal-Gordon > wrote: > >> On Feb 21, 2017, at 8:33 PM, Matthew Johnson wrote: >> >>> A submodule may not import any direct parent module (parent, grandparent, >>> etc.), but may import any other submodule

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

> On Feb 21, 2017, at 11:54 PM, Robert Widmann wrote: > > >> On Feb 22, 2017, at 12:41 AM, Matthew Johnson > > wrote: >> >> >> >> Sent from my iPad >> >> On Feb 21, 2017, at 11:09 PM, Robert Widmann

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

ext: self) { (self, searchQuery) in >>>>> self.performSearch(query: searchQuery) >>>>> } >>>>> ``` >>>>> >>>>> This code neither requires an addition of language features nor contains >>>>> retain c

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

> On Feb 22, 2017, at 8:32 AM, John McCall via swift-evolution > wrote: > > >> On Feb 21, 2017, at 11:50 PM, Chris Lattner wrote: >> >> On Feb 20, 2017, at 11:12 PM, John McCall wrote: As you know, I still think that

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

I like this idea. I think you made the right choice of syntax given the alternatives considered. To me `foo(_)` and `foo(:)` equally imply presence of an argument. The former looks like an anonymous (unnamed) argument and the latter includes the colon which only follows an argument. Between

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

> On Feb 9, 2017, at 2:44 PM, David Hart <da...@hartbit.com> wrote: > > > On 9 Feb 2017, at 20:43, Matthew Johnson via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > >> >> >> Sent from my i

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

Sent from my iPad > On Feb 9, 2017, at 1:30 PM, Hooman Mehr via swift-evolution > wrote: > > >>> On Feb 9, 2017, at 10:47 AM, Joe Groff via swift-evolution >>> wrote: >>> On Feb 9, 2017, at 4:26 AM, Step Christopher via swift-evolution

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

`abstract final class`. > > Regards, > Rien > > Site: http://balancingrock.nl > Blog: http://swiftrien.blogspot.com > Github: http://github.com/Balancingrock > Project: http://swiftfire.nl > > > > > >> On 11 Feb 2017, at 14:07, Matthew Johnson via swift-ev

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

to sub-type (currently only classes are supported). >>>>>> The client is allowed to conform to open protocols >>>>>> The client is allowed to override open type members >>>>>> This also means that extensibility is still allowed to public types. &g

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

> On Feb 11, 2017, at 7:56 AM, Karl Wagner <razie...@gmail.com> wrote: > > >> On 11 Feb 2017, at 14:37, Karl Wagner <karl.sw...@springsup.com >> <mailto:karl.sw...@springsup.com>> wrote: >> >> >>> On 9 Feb 2017, at 00:05, Matthew

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

ll leave us the possibility to think of sub-typing enums in the >>>>> future (I sketched it out a little above). >>>>> >>>> Value subtyping is very interesting. I have been working on some ideas >>>> around this but I want to keep this thread focused

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

Sent from my iPad > On Feb 11, 2017, at 12:44 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote: > >> On Sat, Feb 11, 2017 at 12:42 PM, Matthew Johnson via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> >> Sent from my iP

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

> On Feb 11, 2017, at 7:37 AM, Karl Wagner <razie...@gmail.com> wrote: > > >> On 9 Feb 2017, at 00:05, Matthew Johnson via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> I’ve been thinking

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

7, at 9:48 PM, Xiaodi Wu <xiaodi...@gmail.com > <mailto:xiaodi...@gmail.com>> wrote: > >> On Wed, Feb 8, 2017 at 5:05 PM, Matthew Johnson via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> I’ve been thinking a lot abo

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

osal aims to do is to incorporate it into a >> consistent system of outside-the-module access modifiers. >> >> One can make a very reasonable argument that access modifiers should *only* >> be in the business of talking about visibility and should stay out of the >&g

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

was also an important consideration that I believe applies here. > > Nevin > > > On Sunday, February 12, 2017, Matthew Johnson via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > >> On Feb 12, 2017, at 10:24 AM, David

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

> On Feb 11, 2017, at 4:41 PM, Karl Wagner <razie...@gmail.com> wrote: > > >> On 11 Feb 2017, at 20:50, Matthew Johnson via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >>> >>&g

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

> On Feb 12, 2017, at 10:34 AM, Charlie Monroe via swift-evolution > wrote: > > >> On Feb 12, 2017, at 5:19 PM, David Hart via swift-evolution >> > wrote: >> >> I was reading this nice listing of Swift

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

can add to the set of cases / subclasses / conformances”. The time for that argument was when we had the `open` discussion last year. I happen to like the direction we went because it places `public` and `open` on equal footing. And now that we *have* decided to go in this direction, I think w

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

> On Feb 12, 2017, at 10:19 AM, David Hart via swift-evolution > wrote: > > I was reading this nice listing of Swift keywords > (https://medium.com/the-traveled-ios-developers-guide/swift-keywords-v-3-0-1-f59783bf26c#.2s2yis3zh > >

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

sure we should bother displaying it in generated > interfaces (although the compiler should still be able to take advantage of > it in clients). `final` can be pretty useful when reasoning about code. It’s more than just a performance optimization. It also represents a compiler proof abo

Re: [swift-evolution] Warning when omitting default case for imported enums

> On Feb 10, 2017, at 10:55 AM, Tino Heth via swift-evolution > wrote: > >>> I'm not sure if I like the concept of having two kinds of enum. >> >> Why not? Bool-like enums would be declared ‘closed’, and would not require a >> default case (but adding a new case

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

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 12, 2017, at 2:35 PM, Xiaodi Wu via swift-evolution > wrote: > > _Potentially_ meaningful, certainly. But what I'm hearing is that it isn't > actually meaningful. Here's why: > > If I see `fileprivate` and can understand that to mean "gee, the author >

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

> On Feb 12, 2017, at 3:45 PM, Xiaodi Wu wrote: > > On Sun, Feb 12, 2017 at 3:24 PM, Matthew Johnson > wrote: > >> On Feb 12, 2017, at 2:35 PM, Xiaodi Wu via swift-evolution >>

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

> On Feb 12, 2017, at 3:52 PM, Xiaodi Wu wrote: > > On Sun, Feb 12, 2017 at 3:47 PM, Matthew Johnson > wrote: > >> On Feb 12, 2017, at 3:45 PM, Xiaodi Wu > > wrote:

Re: [swift-evolution] Simplifying Default Access Modifiers

Sent from my iPad > On Feb 13, 2017, at 3:02 AM, Jonathan Hull via swift-evolution > wrote: > > I would like to propose a change to the default access modifier within an > enclosing scope. The default for top level definitions would stay internal, > but anything

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

Sent from my iPad > On Feb 13, 2017, at 1:35 AM, Rien via swift-evolution > wrote: > > >> On 13 Feb 2017, at 06:16, Derrick Ho via swift-evolution >> wrote: >> >> I think I we can live with the original three: public, internal, and

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

of resilient enums, not closed enums. > >> On Feb 8, 2017, at 3:05 PM, Matthew Johnson via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> This proposal introduces the new access modifier `closed` as well as >> clarifying the meaning of `public`

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

> On Feb 13, 2017, at 10:19 AM, Karl Wagner wrote: > >> >>> >>> As I mentioned earlier, I don't think `closed` is a good keyword standing >>> alone. And I also think that, given that we have `open`, `closed` also >>> won't pair well with `public`—they sound like antonyms

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

> On Feb 13, 2017, at 10:14 AM, Adrian Zubarev via swift-evolution > wrote: > > Is that assumption correct? > > // Module A > public protocol SQLiteValue { > init(statement: SQLiteStatement, columnAt index: Int) throws > func bind(to statement:

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.

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

ntracts. If we want keywords with consistent semantics we are going to have to introduce a new keyword for the third meaning. > On Wed, Feb 8, 2017 at 17:05 Matthew Johnson via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > I’ve

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

e better served by annotations and proper semantic versioning. >> >> As this change didn't seem in scope for Swift 4 phase 1, I've held off on >> discussing my own thoughts on access levels. The idea I was going to propose >> in phase 2 was to have simply open and public

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

t; // v1: > case javaScript(String) > case javaScript(String, scope: Document) > > // or v2: > case javaScript(String, scope: Document? = nil) > > > > -- > Adrian Zubarev > Sent with Airmail > > Am 9. Februar 2017 um 16:57:40, Matthew Johnson vi

Re: [swift-evolution] [swift-users] Plan to move swift-evolution and swift-users mailing lists to Discourse

> On Feb 9, 2017, at 11:16 AM, Jens Alfke via swift-users > wrote: > > >> On Feb 9, 2017, at 3:41 AM, Jan Neumüller via swift-users >> > wrote: >> >> I would prefer http://www.fudforum.org/

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

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: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] Reduce with inout

is less a concern with less common and less frequently used signatures. > > On Tue, Jan 24, 2017 at 07:33 Matthew Johnson via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > > > Sent from my iPad > > On Jan 24, 2017, at

Re: [swift-evolution] Reduce with inout

Sent from my iPad > On Jan 24, 2017, at 1:54 AM, Chris Eidhof via swift-evolution > wrote: > > I've thought about it for a few days, and really like `reduce(mutating:_)`. I'm not a fan of this. It reads in a way that makes it seem like the parameter should be

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

tract for enums than they do for classes and protocols. In > fact, `open` for enums would have a contract analagous with `public` for > classes and protocols. This feels like a recipe for confusion. IMO, having > consistent semantics for each keyword is pretty important. We already have,

Re: [swift-evolution] Warning when omitting default case for imported enums

Sent from my iPad > On Feb 11, 2017, at 5:11 AM, Tino Heth via swift-evolution > wrote: > > >> Closed would not be an access level, just an attribute orthogonal to the >> others. > As Xiaodi pointed out, there's still no agreement on that — so basically I'm >

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

Sent from my iPad > On Feb 10, 2017, at 9:48 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote: > >> On Wed, Feb 8, 2017 at 5:05 PM, Matthew Johnson via swift-evolution >> <swift-evolution@swift.org> wrote: >> I’ve been thinking a lot about our public access modi

Re: [swift-evolution] Warning when omitting default case for imported enums

Sent from my iPad > On Feb 10, 2017, at 9:22 PM, Xiaodi Wu via swift-evolution > wrote: > >> On Fri, Feb 10, 2017 at 7:23 PM, Slava Pestov via swift-evolution >> wrote: >> >>> On Feb 10, 2017, at 8:55 AM, Tino Heth <2...@gmx.de> wrote:

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

for `closed`). > > I dislike intensely the contortions I had to go through to justify `open` as > a spelling, and I'd be a little sad to see such reasoning propagate further. > But at the end of the day, I think if we go in with eyes open and explicitly > accept or reject a no

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

ad something like this: > > @closed enum X { > case x, y > func foo() { > switch self { > case .x, .y: > print("swift") > } > } > > enum Z : X { > case z, zz > override func foo() { > // Iff `self

[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

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