Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

> > I like Shawn's proposal: var foo: Int { private(file) set } > In fact it's probably more sensible than the current private(set) IMO. For example, we already use var foo: Int { mutating get { ... } } and not mutating(get) var foo: Int { get { ... } } On Tue, Mar 15, 2016 at 4:13 PM,

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

I like Shawn's proposal: var foo: Int { private(file) set } In fact it's probably more sensible than the current private(set) IMO. While I like private(get: file, set: module) idea, I think it just gets too inconsistent with private(set: public) and private(set: private) (?!) On Tue, Mar 15,

Re: [swift-evolution] [Discussion] Referencing the Objective-C selector of property getters and setters

Another reasonable use case for this is with `UILocalizedIndexedCollation`. For example with Swift 2.1: ``` let collation = UILocalizedIndexedCollation.currentCollation() collation.sectionForObject("something", collationStringSelector: "lowercaseString") // NSString.lowercaseString ```

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

On Mar 14, 2016, at 8:36 PM, Patrick Pijnappel via swift-evolution https://lists.swift.org/mailman/listinfo/swift-evolution>> wrote: > The only question is (as Sean mentioned) how this combines with the syntax > for setter access level, e.g. the current private(set). Options: > - Unnamed 2nd

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

On Mon, Mar 14, 2016 at 5:18 PM Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote: > Per Doug’s email, the core team agrees we should make a change here, but > would like some bikeshedding to happen on the replacement name for private. > > To summarize the place we’d like to

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

> On Mar 14, 2016, at 8:51 PM, Joe Groff via swift-evolution > wrote: > >> >> On Mar 14, 2016, at 8:36 PM, Patrick Pijnappel via swift-evolution >> > wrote: >> >> Another +1 for James' idea to use

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

What about: public private private(module) // instead of internal private(file) or private(test) Eric Sent from my iPhone > On Mar 14, 2016, at 5:41 PM, Erica Sadun via swift-evolution > wrote: > > What color is your bikeshed? > > I don't suppose you'd consider

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

> On Mar 14, 2016, at 8:36 PM, Patrick Pijnappel via swift-evolution > wrote: > > Another +1 for James' idea to use private(module), private(file), private: > - It avoids ambiguity whether internal/private/local is more restrictive and > replaces it with a single

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

On Mon, Mar 14, 2016 at 8:36 PM Patrick Pijnappel via swift-evolution < swift-evolution@swift.org> wrote: > Another +1 for James' idea to use private(module), private(file), private: > - It avoids ambiguity whether internal/private/local is more restrictive > and replaces it with a single axis,

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

> On Mar 14, 2016, at 9:42 PM, Sean Heber via swift-evolution > wrote: > > Although really, why not just use “file” instead of “internal” since it won’t > burn any keywords or cause any other conflicts as far as I know. > > l8r > Sean IMHO, “file” is a reasonable

Re: [swift-evolution] Add an ifPresent function to Optional

I suddenly have a great desire to do a pull-request on https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md -- E, who has admittedly taken on too much today > On Mar 14, 2016, at 9:12 PM, Jordan Rose via swift-evolution > wrote: > > We've

Re: [swift-evolution] Add an ifPresent function to Optional

We've talked about this before, so I'm going to link directly to my (negative) response from back then: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/003697.html. (The rest of the thread is certainly also relevant, but my past opinion is still the one I most identify

Re: [swift-evolution] [Pitch] Make the first parameter in a function declaration follow the same rules as the others

Ah, this doesn't distinguish func foo(bar baz: Int) from func foo(bar bar: Int) That's pretty important for this discussion. (Thanks for actually doing this! I just let it drop last week.) Jordan > On Mar 14, 2016, at 16:01 , Shawn Erickson via swift-evolution >

Re: [swift-evolution] Making `.self` After `Type` Optional

Bumping this - did anything ever become of this? It seemed like there was general agreement to do something about the “.self” requirement when referencing types. I would personally like to see it go away. l8r Sean > On Mar 9, 2016, at 1:23 PM, Tanner Nelson via swift-evolution >

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

Although really, why not just use “file” instead of “internal” since it won’t burn any keywords or cause any other conflicts as far as I know. l8r Sean > On Mar 14, 2016, at 9:38 PM, Sean Heber wrote: > > I, too, prefer it to be more like this: > > public // unchanged >

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

How would you handle translating the existing private(set) and the like with this syntax? It seems like it could get confusing and perhaps end up in a situation where you have something like private(file, set) but then you have to constantly remember which order the parameters are in. l8r Sean

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

I, too, prefer it to be more like this: public // unchanged module // currently internal internal // currently private private // new hotness l8r Sean > On Mar 14, 2016, at 7:50 PM, Jo Albright via swift-evolution > wrote: > > +1 > > I like this a lot.

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

> On Mar 14, 2016, at 8:57 PM, Erica Sadun via swift-evolution > wrote: > > >> On Mar 14, 2016, at 7:50 PM, Joe Groff via swift-evolution >> wrote: >> >> >>> On Mar 14, 2016, at 6:47 PM, Ilya Belenkiy via swift-evolution >>>

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

> On Mar 14, 2016, at 7:50 PM, Joe Groff via swift-evolution > wrote: > > >> On Mar 14, 2016, at 6:47 PM, Ilya Belenkiy via swift-evolution >> wrote: >> >> I really like James's idea: >> >> private symbol visible within

Re: [swift-evolution] [META] Re-invigorating the compiler directive discussion

> On Mar 14, 2016, at 3:03 PM, Dmitri Gribenko via swift-evolution > wrote: > > On Mon, Mar 14, 2016 at 2:23 PM, Erica Sadun > wrote: >> >>> On Mar 14, 2016, at 3:12 PM, Dmitri Gribenko

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

> On Mar 14, 2016, at 6:47 PM, Ilya Belenkiy via swift-evolution > wrote: > > I really like James's idea: > > private symbol visible within the current declaration (class, > extension, etc). > private(module) symbol visible within the current

Re: [swift-evolution] Add an ifPresent function to Optional

On Mon, Mar 14, 2016 at 5:51 PM, wrote: > > On Mar 14, 2016, at 5:51 PM, Dmitri Gribenko via swift-evolution > wrote: > > Optional.map returns an Optional. > > Array.map returns an Array. > Set.map returns an Array. > .map returns an Array. > > I

Re: [swift-evolution] [Draft] Throwing Properties and Subscripts

> On Mar 14, 2016, at 4:59 PM, Brent Royal-Gordon > wrote: > >> Do you have an imagined use for throwing getters? > > In the proposal, I cite a pair of framework methods that I think would be > better modeled as a throwing subscript: > > class NSURL { >

Re: [swift-evolution] Simplifying Function Parameter List (when calling)

> On Mar 14, 2016, at 4:34 PM, Ted F.A. van Gaalen via swift-evolution > wrote: > > (spawned from subject: "Make the first parameter in a function follow the > same rules as the others”) > > Idea: Eliminate commas from the parameter list when calling a function, >

Re: [swift-evolution] [Draft] Throwing Properties and Subscripts

> On Mar 14, 2016, at 6:08 PM, Step C wrote: > > Joe, was there an off-list email? I don't see your comments in my mail client > or on Mailman, only quoted by Brent. Not to my knowledge. -Joe ___ swift-evolution

Re: [swift-evolution] [Draft] Throwing Properties and Subscripts

Joe, was there an off-list email? I don't see your comments in my mail client or on Mailman, only quoted by Brent. On Mar 14, 2016, at 7:59 PM, Brent Royal-Gordon via swift-evolution wrote: >> Do you have an imagined use for throwing getters? > > In the proposal, I

Re: [swift-evolution] Add an ifPresent function to Optional

> On Mar 14, 2016, at 5:51 PM, Dmitri Gribenko via swift-evolution > wrote: > > Optional.map returns an Optional. > > Array.map returns an Array. > Set.map returns an Array. > .map returns an Array. > > I can't say that it is not valid to think about an Optional as

Re: [swift-evolution] Should all GeneratorTypes also be SequenceTypes?

On Mon, Mar 14, 2016 at 4:42 PM, Haravikk via swift-evolution wrote: > There are quite a lot of generator implementations that also implement > SequenceType (since it’s as simple as returning self). Indeed, the > AnyGenerator type conforms to SequenceType, allowing

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

+1 I like this a lot. Name ideas : enclosed, filelocal, fileonly, filelock, fileaccess, fileprivate, insidefile, inner. I also like Erica’s filebound & file fixed. By Erica’s suggestion about switching… - public - modular, modulelock, packaged (module only) - internal (file only) - private

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

> On Mar 14, 2016, at 5:18 PM, Chris Lattner via swift-evolution > wrote: > > Per Doug’s email, the core team agrees we should make a change here, but > would like some bikeshedding to happen on the replacement name for private. > > To summarize the place we’d like

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

On Mon, Mar 14, 2016 at 5:18 PM Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote: > Per Doug’s email, the core team agrees we should make a change here, but > would like some bikeshedding to happen on the replacement name for private. > > To summarize the place we’d like to

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

What color is your bikeshed? I don't suppose you'd consider swapping private and internal (since the opposite of public is private, and internal means inside)? Anyway, there's fileScoped (or filescoped), access(file) (which has the option of being used for access with module and global),

Re: [swift-evolution] [Draft] Throwing Properties and Subscripts

> >> Do you have an imagined use for throwing getters? The project I work on — a database engine — has an API with a lot of things that are conceptually properties, but whose accessors can fail because they may have to read or write

[swift-evolution] SE-0025: Scoped Access Level, next steps

Per Doug’s email, the core team agrees we should make a change here, but would like some bikeshedding to happen on the replacement name for private. To summarize the place we’d like to end up: - “public” -> symbol visible outside the current module. - “internal” -> symbol visible within the

Re: [swift-evolution] [Pitch] Introducing #fileName debug identifier

> On Mar 14, 2016, at 1:49 PM, Erica Sadun wrote: > > >> On Mar 14, 2016, at 2:37 PM, Chris Lattner > > wrote: >> If it is practical to get the module-relative path, I’d rather see us switch >> #file to produce *that*, and

Re: [swift-evolution] [Draft] Throwing Properties and Subscripts

> Do you have an imagined use for throwing getters? In the proposal, I cite a pair of framework methods that I think would be better modeled as a throwing subscript: class NSURL { func getResourceValue(_ value: AutoreleasingUnsafeMutablePointer, forKey key:

[swift-evolution] Should all GeneratorTypes also be SequenceTypes?

There are quite a lot of generator implementations that also implement SequenceType (since it’s as simple as returning self). Indeed, the AnyGenerator type conforms to SequenceType, allowing any generator to be wrapped as a sequence, though I imagine this comes with some overhead. So it got me

Re: [swift-evolution] [Pitch] Make the first parameter in a function declaration follow the same rules as the others

I could have easily screwed up my grep but doing spot checks on the resulting data sets I didn't spot an issue. I did make assumptions about how well formed the data set was. [shawnce:~/Downloads/swift-3-api-guidelines-review-swift-3] [0:554]> grep -R "func [A-Za-z0-9]*([A-Za-z0-9]*

Re: [swift-evolution] [Proposal] Add an API to Unmanaged to get the instance it holds "@guaranteed"

> On Mar 14, 2016, at 3:08 PM, Arnold Schwaighofer via swift-evolution > wrote: > >> >> On Mar 14, 2016, at 1:29 PM, John McCall wrote: >> >>> On Mar 14, 2016, at 12:51 PM, Arnold Schwaighofer >>> wrote: On Mar

Re: [swift-evolution] Add an ifPresent function to Optional

On Mon, Mar 14, 2016 at 3:44 PM, Erica Sadun wrote: >> No. My argument is that map on collections and on optionals are two >> completely different things. They unify on a level that does not >> exist in Swift (higher-kinded types). We could name Optional.map() >>

Re: [swift-evolution] [META] Re-invigorating the compiler directive discussion

> On Mar 14, 2016, at 4:03 PM, Dmitri Gribenko wrote: > The use cases for this one are clear to me, you can find many in > low-level code. I think the majority of the #if's found in the > standard library are either checks for 32/64 bit, or ObjC/Native > runtime, or

Re: [swift-evolution] Add an ifPresent function to Optional

> No. My argument is that map on collections and on optionals are two > completely different things. They unify on a level that does not > exist in Swift (higher-kinded types). We could name Optional.map() > differently, and that would be a separate decision from renaming > Collection.map(),

Re: [swift-evolution] Add an ifPresent function to Optional

On Fri, Mar 11, 2016 at 7:17 PM, Howard Lovatt via swift-evolution wrote: > @Dave, Yes, CollectionType would be better than SequenceType. We already considered doing this a long time ago, and we decided against it. 1. `for x in y {}` would start working everywhere

Re: [swift-evolution] Add an ifPresent function to Optional

On Mar 14, 2016, at 4:33 PM, Dmitri Gribenko wrote: > > On Mon, Mar 14, 2016 at 1:28 PM, Erica Sadun via swift-evolution > wrote: >> >>> On Mar 14, 2016, at 2:18 PM, Daniel Vollmer via swift-evolution >>> wrote: >>>

Re: [swift-evolution] [Revision] SE-0034 - Disambiguating Line Control Statements from Debugging Identifiers

on Fri Mar 11 2016, Chris Lattner wrote: > This provides syntax that looks like an imperative function call that > affects the logical source location at that point in the file. FWIW, to me it looks like a declarative statement about how the compiler should treat the