Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

> On Mar 21, 2017, at 11:03 PM, Chris Lattner via swift-evolution > wrote: > > * What is your evaluation of the proposal? I'm going to have to come down on the "no" side on this one. I'm actually not worried about methods so much as properties. KVC is completely

Re: [swift-evolution] [Proposal] [Discussion] Explicit Toll-Free Conversions

> On Mar 23, 2017, at 6:41 AM, Slava Pestov via swift-evolution > wrote: > > >> On Mar 22, 2017, at 10:35 PM, Robert Widmann via swift-evolution >> > wrote: >> >> Alternatives considered >> >> Do

Re: [swift-evolution] [Proposal] [Discussion] Explicit Toll-Free Conversions

Correct. This section is referring more to the NS-side of things. > On Mar 23, 2017, at 1:38 AM, Slava Pestov wrote: > > >> On Mar 22, 2017, at 10:35 PM, Robert Widmann via swift-evolution >> > wrote: >> >> This

Re: [swift-evolution] [Proposal] [Discussion] Explicit Toll-Free Conversions

> On Mar 22, 2017, at 10:35 PM, Robert Widmann via swift-evolution > wrote: > > Alternatives considered > > Do nothing and continue to accept this implicit conversion. One alternative would be to import CFArray as a typealias for NSArray, etc, erasing the

Re: [swift-evolution] [Proposal] [Discussion] Explicit Toll-Free Conversions

> On Mar 22, 2017, at 10:35 PM, Robert Widmann via swift-evolution > wrote: > > This introduces a source-breaking change that affects consumers of APIs that > are explicitly taking or vending instances of bridged CF or Objective-C > types. However, recent importer

[swift-evolution] [Proposal] [Discussion] Explicit Toll-Free Conversions

Good evening all, Attached is the proposal text that came out of a short discussion on Twitter about squashing one more case of implicit conversions in the language. This proposal seeks to remove the implicit nature of toll-free

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

> On Mar 23, 2017, at 12:02 AM, Douglas Gregor via swift-evolution > wrote: > > >> On Mar 22, 2017, at 3:22 PM, Haravikk via swift-evolution >> wrote: >> >> >>> On 22 Mar 2017, at 06:03, Chris Lattner via swift-evolution >>>

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

It has been expressed in various ways "does anybody actually use scoped visibility in the wild" and "what real benefit does it provide to production code". The below file or some estranged stepchild of it appears at least 5 repositories (that I know of; this is practically a samizdat around

Re: [swift-evolution] Swift null safety questions

On March 22, 2017 at 8:41:25 PM, Joe Groff (jgr...@apple.com) wrote: > On Mar 22, 2017, at 4:07 PM, Elijah Johnson wrote: > > Hi, > > Note that this thread has branched off a bit, so my latest proposal and the “head” of this thread can be found at

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

I strongly prefer that “private” should mean “visible in the current file”. I am ambivalent between eliminating the scoped access level or renaming it “scoped”, as long as “private” once more denotes file-level visibility. Nevin ___ swift-evolution

Re: [swift-evolution] Swift null safety questions

On March 22, 2017 at 8:48:27 PM, Joe Groff (jgr...@apple.com) wrote: > On Mar 21, 2017, at 6:27 AM, Elijah Johnson via swift-evolution < swift-evolution@swift.org> wrote: > > I still like the idea of shared memory, but since without additional threading it can’t have write access inside the new

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

> > * What is your evaluation of the proposal? > +1 in intent and -1 in detail. I think reducing the amount of magic helps make swift more powerful and easier to understand. This will force developers to add a few more `@objc` tokens, but the consistency will help in the long run. The last

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

+1 What is "current private" can be replicated with the new behavior, use of files, and use of modules. On Wed, Mar 22, 2017 at 8:59 PM, Jordan Rose via swift-evolution < swift-evolution@swift.org> wrote: > > On Mar 21, 2017, at 15:26, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org>

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

> On Mar 21, 2017, at 15:26, Xiaodi Wu via swift-evolution > wrote: > > The kicker is, _it also doesn't work_. Try, for instance: > > ``` > struct Foo { > private var bar: Int { return 42 } > } > > extension Foo { > private var bar: Int { return 43 } > } > ```

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

[Proposal: https://github.com/apple/swift-evolution/blob/master/proposals/0160-objc-inference.md] I'm definitely in favor of this. Apart from the various motivations discussed in the proposal, this also allows some changes that could improve incremental builds: the generated header

Re: [swift-evolution] Swift null safety questions

> On Mar 21, 2017, at 6:27 AM, Elijah Johnson via swift-evolution > wrote: > > I still like the idea of shared memory, but since without additional > threading it can’t have write access inside the new process, I don’t think > that it is a solution for a webserver.

Re: [swift-evolution] Swift null safety questions

> On Mar 22, 2017, at 4:07 PM, Elijah Johnson wrote: > > Hi, > > Note that this thread has branched off a bit, so my latest proposal and the > “head” of this thread can be found at > https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170320/034189.html > >

Re: [swift-evolution] Swift null safety questions

TLDR version, I would check with the developers of Swift web servers (Vapor, Kitura, etc) if this is their actual plan also to re-work their webserver using actors and processes instead of threads. I’m not writing a webserver myself, so that is what it should come down to. Right now, if you unwrap

Re: [swift-evolution] Swift null safety questions

Hi, Note that this thread has branched off a bit, so my latest proposal and the “head” of this thread can be found at https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170320/034189.html Can you give an example of this corruption which would be exploitable in a web server

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

> On Mar 22, 2017, at 3:22 PM, Haravikk via swift-evolution > wrote: > > >> On 22 Mar 2017, at 06:03, Chris Lattner via swift-evolution >> wrote: >> * What is your evaluation of the proposal? > > In favour. > > Like others I can

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

> On 22 Mar 2017, at 06:03, Chris Lattner via swift-evolution > wrote: > * What is your evaluation of the proposal? In favour. Like others I can foresee there being a bit of pain for some developers, but I think it's worth it to be more explicit about what's going

Re: [swift-evolution] Smart KeyPaths

By the way, I am okay with the syntax in the proposal too. I'm just brainstorming so that we can look at all the options. I am guessing the authors (David Smith, Michael LeHew and Joe Groff) probably went through this process already and settled with the simpler notation. :-) > On Mar 22,

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

> On Mar 22, 2017, at 3:30 AM, Rien wrote: > > I am less sanguine about the burden of proof. > > Imo there is no absolute and irrevocable proof needed to accept or reject a > change proposal. I'm sorry, I used an idiomatic phrase which may not be obvious to non-native

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

On Wed, Mar 22, 2017, at 01:58 PM, Kevin Ballard wrote: > On Mon, Mar 20, 2017, at 04:54 PM, Douglas Gregor wrote: >> * What is your evaluation of the proposal? > > Huge -1, and I agree strongly with Drew Crockford's emails on > this topic. My apologies, Drew. It's Drew Crawford. -Kevin

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

On Mon, Mar 20, 2017, at 04:54 PM, Douglas Gregor wrote: > * What is your evaluation of the proposal? Huge -1, and I agree strongly with Drew Crockford's emails on this topic. -Kevin Ballard ___ swift-evolution mailing list swift-evolution@swift.org

Re: [swift-evolution] Smart KeyPaths

Yes, I was about to ask the same. It seems like all the sigil characters are taken. This is one of the reasons why I did not object to the non-sigil notation originally proposed despite the ambiguity with static properties and instance properties with the same name. But using a sigil seems

Re: [swift-evolution] Smart KeyPaths

> On Mar 22, 2017, at 3:30 PM, Brent Royal-Gordon > wrote: > >> On Mar 22, 2017, at 11:27 AM, Matthew Johnson via swift-evolution >> > wrote: >> >> One option would be to include `get` and `set` methods on

Re: [swift-evolution] Smart KeyPaths

> On Mar 22, 2017, at 11:27 AM, Matthew Johnson via swift-evolution > wrote: > > One option would be to include `get` and `set` methods on the key path types. > That would allow us to write the subscripts in the standard library (if it > is allowed to extend Any)

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

Very much in favour of this - access modifiers in swift became way to confusing.. and the usefulness is limited. Keep it simple I say. THAT benefits swift the most in the long run Kind Regards Dominik Web: https://pich.info Twitter: @DaijDjan Facebook: Dominik.Pich > On 22 Mar 2017, at 21:20,

Re: [swift-evolution] [Proposal] Factory Initializers

> Le 21 mars 2017 à 22:09, Jonathan Hull via swift-evolution > a écrit : > > There are several reasons. It is a very common pattern in ObjC/Cocoa. For > example, they allow class clusters (and the protocol equivalent). I don’t see that as a strong argument for

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

- What is your evaluation of the proposal? Definitely in favor of this. About halfway through the Swift 3 migration I gave up trying to think through where to use fileprivate and where to use private and just did a project level find and replace to use fileprivate everywhere. So far over the

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

* What is your evaluation of the proposal? In theory, it seems like a great idea, but I fear that it will be one of those small changes that have disastrous effects on migrating code to Swift 4. There will likely be a ton of confusing errors and warnings that amount to "just add @objc to

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

On 2017-03-20 23:54:47 +, Douglas Gregor via swift-evolution said: • What is your evaluation of the proposal? -1. I share Drew Crawford's concerns regarding the proposal. -- Bouke___ swift-evolution mailing list

Re: [swift-evolution] Smart KeyPaths

> One option would be to include `get` and `set` methods on the key path types. > That would allow us to write the subscripts in the standard library (if it > is allowed to extend Any) and keep all of the magic in the key path types > themselves. I think I would like that approach. +1 l8r

Re: [swift-evolution] Smart KeyPaths

> On Mar 22, 2017, at 9:00 AM, Vladimir.S via swift-evolution > wrote: > > bag[#path] What do these do? bag[#file] bag[#line] bag[#function] // etc. -- Brent Royal-Gordon Architechies ___

Re: [swift-evolution] Smart KeyPaths

> On Mar 22, 2017, at 12:34 PM, Vladimir.S wrote: > > On 22.03.2017 19:25, Matthew Johnson wrote: >> >>> On Mar 22, 2017, at 11:00 AM, Vladimir.S >> > wrote: >>> >>> On 22.03.2017 18:47, Matthew Johnson wrote: > On Mar

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

Hi Ben, What’s the use case that you were thinking of? `KeyPath`s could be useful in the case where you don’t need to customize your key names, but cannot represent a custom case like ```swift public struct Post { var authorID: Int var bodyText: String private enum CodingKeys :

Re: [swift-evolution] Smart KeyPaths

On 22.03.2017 19:25, Matthew Johnson wrote: On Mar 22, 2017, at 11:00 AM, Vladimir.S > wrote: On 22.03.2017 18:47, Matthew Johnson wrote: On Mar 22, 2017, at 10:36 AM, Vladimir.S via swift-evolution

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

> On Mar 22, 2017, at 7:50 AM, Michel Fortin via swift-evolution > wrote: > >> * What is your evaluation of the proposal? > > Good. I'll certainly appreciate the added clarity of knowing which methods > are exposed to Objective-C. > > Currently, Swift-only apps

Re: [swift-evolution] Swift null safety questions

> On Mar 22, 2017, at 10:09 AM, Matthew Johnson wrote: > >> >> On Mar 22, 2017, at 12:03 PM, Joe Groff via swift-evolution >> > wrote: >> >> >>> On Mar 6, 2017, at 4:20 PM, Elijah Johnson via

Re: [swift-evolution] Swift null safety questions

> On Mar 22, 2017, at 12:03 PM, Joe Groff via swift-evolution > wrote: > > >> On Mar 6, 2017, at 4:20 PM, Elijah Johnson via swift-evolution >> > wrote: >> >> Hi, >> >> I’ve been recently considering

Re: [swift-evolution] Swift null safety questions

> On Mar 6, 2017, at 4:20 PM, Elijah Johnson via swift-evolution > wrote: > > Hi, > > I’ve been recently considering Swift on the server-side, and there came up > the question, “what happens when a null optional is forcibly unwrapped?” and > the answer was clearly

Re: [swift-evolution] Smart KeyPaths

> On Mar 22, 2017, at 11:41 AM, Ricardo Parada wrote: > > Agree. > > Another question. If `Bag` does have a static thing called `myStaticThingy` > would you refer to it as: > > Bag.Type#myStaticThingy I would expect that to work eventually but I’m not sure if it would be

Re: [swift-evolution] Smart KeyPaths

Agree. Another question. If `Bag` does have a static thing called `myStaticThingy` would you refer to it as: Bag.Type#myStaticThingy ? > On Mar 22, 2017, at 12:37 PM, Matthew Johnson wrote: > >> >> On Mar 22, 2017, at 11:16 AM, Ricardo Parada >

Re: [swift-evolution] Smart KeyPaths

> On Mar 22, 2017, at 11:16 AM, Ricardo Parada wrote: > > I see three possibilities: > > 1) # + «space» +«path» like this: > > let path = # Bag.things[0].name > bag[path] > bag[# Bag.things[0].name] > bag[# .things[0].name] // Root is inferred as Bag > bag.things[0][#

Re: [swift-evolution] Smart KeyPaths

> On Mar 22, 2017, at 11:00 AM, Vladimir.S wrote: > > On 22.03.2017 18:47, Matthew Johnson wrote: >> >>> On Mar 22, 2017, at 10:36 AM, Vladimir.S via swift-evolution >>> > wrote: >>> >>> On 22.03.2017 17:37,

Re: [swift-evolution] Smart KeyPaths

I see three possibilities: 1) # + «space» +«path» like this: let path = # Bag.things[0].name bag[path] bag[# Bag.things[0].name] bag[# .things[0].name] // Root is inferred as Bag bag.things[0][# Thing.name] bag.things[0][# .name] // Root is inferred as Thing 2) # + «path» like this:: let

Re: [swift-evolution] Smart KeyPaths

On 22.03.2017 18:47, Matthew Johnson wrote: On Mar 22, 2017, at 10:36 AM, Vladimir.S via swift-evolution > wrote: On 22.03.2017 17:37, Ricardo Parada wrote: On Mar 22, 2017, at 9:30 AM, Vladimir.S

Re: [swift-evolution] Smart KeyPaths

> On Mar 22, 2017, at 10:36 AM, Vladimir.S via swift-evolution > wrote: > > On 22.03.2017 17:37, Ricardo Parada wrote: >> >> >>> On Mar 22, 2017, at 9:30 AM, Vladimir.S wrote: >>> >>> let path = @Bag.things[0].name >>> >>> bag@path >>>

Re: [swift-evolution] Smart KeyPaths

On 22.03.2017 17:37, Ricardo Parada wrote: On Mar 22, 2017, at 9:30 AM, Vladimir.S wrote: let path = @Bag.things[0].name bag@path bag@.things[0].name bag@Bag.things[0].name bag.things[0]@.name bag.things[0]@Thing.name It sounds like the @ character is serving two

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

- What is your evaluation of the proposal? +1 I'm generally a proponent of scoped access control and have been torn over this proposal. What finally pushed me over the edge has been the time I've taken to review others code. I've got a team of about 32 iOS developers and their code shows a

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

What is your evaluation of the proposal? I agree with the proposal. While I acknowledge that a lexically-scoped access modifier can be useful, giving it the name “private” in Swift is unfortunate. Much of the existing Swift training material suggests a common pattern of adding protocol

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

What is your evaluation of the proposal? –1 However I do support the reverting meaning of the keyword, but I’m against obliterating the powerful scoped access modifier. That said, I’m against the breaking change for Swift–4, which only fixes a tiny peace of the access control system. Is the

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

> * What is your evaluation of the proposal? +1. This clarifies the interaction between Swift and Objective-C and reduces the magic that exists for bridging. It’s one more step on the road of Swift relying less on the Objective-C runtime - decoupling the semantics of `dynamic` from `@objc`

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

> * What is your evaluation of the proposal? Good. I'll certainly appreciate the added clarity of knowing which methods are exposed to Objective-C. Currently, Swift-only apps are bloated by unnecessary Objective-C thunks. The motivation section says that this will reduce the reduce the binary

Re: [swift-evolution] Smart KeyPaths

> On Mar 22, 2017, at 9:30 AM, Vladimir.S wrote: > > let path = @Bag.things[0].name > > bag@path > bag@.things[0].name > bag@Bag.things[0].name > bag.things[0]@.name > bag.things[0]@Thing.name It sounds like the @ character is serving two different purposes which confused

Re: [swift-evolution] [Accepted] SE-0156: Class and Subtype existentials

Do we support where clauses on these existentials? For example, can I write: func doSomething(_: NSObject & Collection where Iterator.Element == T) The proposal says nothing about where clauses. - Karl > > On Mar 20, 2017 at 7:00 pm,

Re: [swift-evolution] [Accepted] SE-0156: Class and Subtype existentials

> On Mar 22, 2017, at 7:12 AM, Karl Wagner wrote: > > Do we support where clauses on these existentials? For example, can I write: > > func doSomething(_: NSObject & Collection where Iterator.Element == T) > > The proposal says nothing about where clauses. No, this

Re: [swift-evolution] Smart KeyPaths

On 22.03.2017 6:01, Ricardo Parada via swift-evolution wrote: Sometimes I feel like we need a winning sigil for this, one that would look good, it is not already taken and easy to type in all keyboards. Maybe we'll have to start looking at emojis :-) IMO syntax for method references should

[swift-evolution] Generalised concrete-type existentials

I'd also like to see this. I expect there would be plenty of support if this got to the proposal stage, but I think you've already got the discussion covered quite comprehensively. I think the class existential proposal made sense for this stage of Swift evolution because there were known APIs

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

> On 15 Mar 2017, at 22:40, Itai Ferber wrote: > > The following introduces a new Swift-focused archival and serialization API > as part of the Foundation framework. We’re interested in improving the > experience and safety of performing archival and serialization, and are happy > to receive

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

> Imo there is no absolute and irrevocable proof needed to accept or reject a > change proposal. very true — because for many proposals, there won't ever be any sort of proof for their effect (positive or negative). Sometimes, there is general agreement that a change is a real improvement,

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

> On 22 Mar 2017, at 10:53, Goffredo Marocchi via swift-evolution > wrote: > > > Sent from my iPhone > > On 22 Mar 2017, at 09:43, Brent Royal-Gordon via swift-evolution > wrote: > >>> On Mar 21, 2017, at 11:29 PM, Matt Whiteside via

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

Sent from my iPhone > On 22 Mar 2017, at 09:43, Brent Royal-Gordon via swift-evolution > wrote: > >> On Mar 21, 2017, at 11:29 PM, Matt Whiteside via swift-evolution >> wrote: >> >> One point which was raised by a couple of different

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

> On Mar 21, 2017, at 11:29 PM, Matt Whiteside via swift-evolution > wrote: > > One point which was raised by a couple of different people on this thread > (Brent Royal-Gordon, Jonathan Hull), which gave me some hesitation in voting > in favor of this proposal, is

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

> On 22 Mar 2017, at 03:16, Xiaodi Wu wrote: > >> On Tue, Mar 21, 2017 at 9:38 PM, Matthew Johnson wrote: >> >>> On Mar 21, 2017, at 9:28 PM, Xiaodi Wu wrote: >>> >>> And couldn't this be enforced by a linter feature that warns if a private >>> member beginning with _ is accessed outside of

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

+1 > * What is your evaluation of the proposal? Seems to remove magic, which is something I can support, even if it means refactoring existing code. > * Is the problem being addressed significant enough to warrant a change to > Swift? Neutral > * Does this proposal fit well with the feel

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

> What is your evaluation of the proposal? +1. > Is the problem being addressed significant enough to warrant a change to > Swift? Yes. Even though I can see how scoped access is occasionally useful, I know that it comes at the cost of implementation complexity, which slows down other

[swift-evolution] [Review] SE-0160: Limiting @objc inference

Hello Swift community, The review of "SE-0160: Limiting @objc inference" begins now and runs through March 28. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0160-objc-inference.md Reviews are an important part of the Swift evolution