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

Let me vote +1 for splitting it. The added conceptual complexity should be minimal, since it is progressively disclosed. You only need to know about codeable, unless you run into the issue where you only want one, at which point stack overflow, etc… will point you to Encodable/Decodable and

Re: [swift-evolution] Pitch: Partial Implementations

On 23.03.2017 21:21, Matthew Johnson via swift-evolution wrote: On Mar 23, 2017, at 1:12 PM, Charles Srstka via swift-evolution wrote: MOTIVATION: In current Swift, a pattern has emerged among some developers, in order to logically group parts of a class or

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

> On Mar 23, 2017, at 11:35 AM, Rien via swift-evolution > wrote: > > >> On 21 Mar 2017, at 08:05, Rien wrote: >> >> +1 > > -1: I have revised my opinion. > > >> >>> • What is your evaluation of the proposal? >> >> Makes the

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

I'm curious to hear what issue your client had with you using many frameworks that static linking doesn't solve. The issue here is the number of frameworks that the user drags and drops into Xcode.  Most libraries ship as a single framework, see this page for a typical example of what the

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

We could spell the new attribute @objcMembers or something like that. Slava > On Mar 23, 2017, at 10:03 AM, Jordan Rose wrote: > > What happens for people using @objc to choose the class's runtime name? It > seems unfortunate to conflate that with changed inference. >

Re: [swift-evolution] Pitch: Partial Implementations

> On Mar 23, 2017, at 2:45 PM, Matthew Johnson wrote: > > Sure, but this does effectively violate lexical scope boundaries as they > exist in the original source. If the yeas have it on SE-0159, and “private” is turned into “fileprivate”, the lexical scope boundaries

Re: [swift-evolution] Pitch: Partial Implementations

-1 I would much rather see the ability to introduce stored properties in extensions (within the module) + simple file-based submodules. Also, I think you are missing important parts of the extensions + fileprivate pattern. Sure, a big part of it is being able to group conformances together

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

Big -1 from me. The introduction of private/fileprivate access levels was a huge win for Swift 3. I would really hate to see it go. > Hello Swift community, > > The review of SE-0159 "Fix Private Access Levels" begins now and runs through > March 27, 2017. The proposal is available here: > >

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

> On Mar 23, 2017, at 1:46 AM, Slava Pestov via swift-evolution > wrote: > > >> On Mar 22, 2017, at 5:51 PM, Jordan Rose via swift-evolution >> wrote: >> >> [Proposal: >>

Re: [swift-evolution] Pitch: Partial Implementations

> On Mar 23, 2017, at 2:37 PM, Charles Srstka wrote: > >> On Mar 23, 2017, at 2:15 PM, Matthew Johnson > > wrote: >> >> What I’m suggesting is that we could accomplish the same functionality by >> enhancing

Re: [swift-evolution] Pitch: Partial Implementations

> On Mar 23, 2017, at 11:21 AM, Matthew Johnson via swift-evolution > wrote: > > 1) Allow stored properties in same-module extensions. This has been > discussed in the past and is a possibility, but I suspect it is not in scope > for consideration during Swift 4.

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

> On Mar 23, 2017, at 10:47 AM, Philippe Hausler wrote: > > >> On Mar 23, 2017, at 10:14 AM, Jordan Rose > > wrote: >> >>> >>> On Mar 23, 2017, at 09:05, Joe Groff via swift-evolution >>>

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

On March 23, 2017 at 12:32:38 PM, Brent Royal-Gordon (br...@architechies.com) wrote: To what extent could your need for safety be satisfied by (a) giving the property a long, unique name like `unsafeUnsynchronizedT`, and (b) writing a very small unit test/shell script/Perl script which

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

Fantastic. Great to hear. I look forward to reading the revised proposal! Regards > On 24 Mar 2017, at 3:34 am, Itai Ferber wrote: > > Hi Oliver, > > Thanks for your comments! We thought about this and we agree overall — we > will incorporate this suggestion along with

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

A further benefit of this scheme is that it makes the behavior of @objc on class members consistent between NSObject-derived and Swift-native classes. Right now, it is legal to apply @objc to a _member_ of a Swift-native class; this is what allows Swift-native classes to model @objc protocols

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

> On Mar 22, 2017, at 10:34 PM, Charlie Monroe via swift-evolution > wrote: > >> >> 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 >>>

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

> On Mar 22, 2017, at 5:51 PM, Jordan Rose via swift-evolution > wrote: > > [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

Re: [swift-evolution] Swift null safety questions

> On 23 Mar 2017, at 02:25, Elijah Johnson via swift-evolution > wrote: > > 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 > >

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

> On Mar 22, 2017, at 10:55 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> 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

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

Here’s an idea for working around the problem of the lack of static knowledge during migration. Probably it’s kind of tacky and won’t get much traction in it’s current form, but it might start some useful discussion at least. Right now, @objc when applied to a _class_ is completely useless; if

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

> On Mar 23, 2017, at 8:35 PM, Matthew Johnson via swift-evolution > wrote: > > On Mar 23, 2017, at 8:27 PM, Drew Crawford > wrote: > >> >> >> >> Sent from my iPhone >> On Mar 23, 2017, at 6:41 PM, David

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

> On 23 Mar 2017, at 20:18, Matthew Johnson wrote: > > >> On Mar 23, 2017, at 2:02 PM, David Hart via swift-evolution >> > wrote: >> >> >> >> On 23 Mar 2017, at 16:49, Drew Crawford

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

Given that this is such a divisive issue, I'd like to see a revised version of this proposal that renames fileprivate back to private but maintains scoped access control under a different name like "scoped", as has been suggested. That seems like the best compromise -- those that want scoped

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

> On Mar 23, 2017, at 10:54 AM, Zach Waldowski via swift-evolution > wrote: > > It is equally frustrating that those on the opposite side of this proposal > keep indicating “just don’t pay attention to it” is an acceptable answer to > the language growing an

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

Sent from my iPhone > On Mar 23, 2017, at 6:41 PM, David Hart wrote: > > I have difficulties imagining a submodule proposal that could allow us to > eliminate fileprivate. Care to give an example? The obvious example would be Rust. Rust has exactly two visibilities, and

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

Sent from my iPad > On Mar 23, 2017, at 8:27 PM, Drew Crawford wrote: > > > > > Sent from my iPhone > On Mar 23, 2017, at 6:41 PM, David Hart wrote: > >> I have difficulties imagining a submodule proposal that could allow us to >> eliminate

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

Hello Swift community, > > The review of SE-0159 "Fix Private Access Levels" begins now and runs through March 27, 2017. The proposal is available here: > > https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md > Reviews are an important part of the

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

> On 23 Mar 2017, at 21:49, Drew Crawford wrote: > >> I'm curious to hear what issue your client had with you using many >> frameworks that static linking doesn't solve. > > The issue here is the number of frameworks that the user drags and drops into > Xcode. Most

Re: [swift-evolution] Pitch: Partial Implementations

> On 23 Mar 2017, at 21:36, Slava Pestov via swift-evolution > wrote: > > >> On Mar 23, 2017, at 11:21 AM, Matthew Johnson via swift-evolution >> > wrote: >> >> 1) Allow stored properties in same-module

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

Big -1 from me. While I don't like fileprivate at all, removing private as it presently exists is not the answer. For details on my thoughts, please refer to Drew Crawford's excellent responses to this proposal; he states it far better than I ever could :) -- Gwynne Raskind > On Mar 20, 2017,

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

I would like to separately concur with (most of) Matt's excellent review.  He identifies what I think the core issues here, which are People code in different styles.  A scoped keyword is more useful in some styles and less useful in others, and this debate is in many ways a proxy war about

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

> But with static linking, your user wouldn’t have to drag 4 .a libraries but > only one, which contains all libraries statically linked together. Static linking is unrelated to merging modules. We can statically link libraries on Linux right now, this does not reduce the files on disk or

Re: [swift-evolution] Proposed amendment to SE-0138: Normalize UnsafeRawBufferPointer Slices

The convenience initialiser should exist on all of the unsafe buffers, not just the raw (untyped) ones. I’ve run in to this problem a few times, and I think it would get worse if we adopted a ContiguouslyStored protocol to formalise accessing the raw-pointers of generic collections. It would

Re: [swift-evolution] Proposed amendment to SE-0138: Normalize UnsafeRawBufferPointer Slices

Oh, one more thing (about this specific change): If we do this, we should add an “offset” parameter to UnsafeMutableBufferPointer.[move]initialize/assign (with a default of 0 for source compatibility). Otherwise, it becomes awkward to initialise a region of a buffer from another buffer. What I

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

Or, since many designs for submodules are possible, we can proceed to make the best decision *now* with respect to access levels, confident that there will be a good design for submodules whether or not there exist both scoped and file-based private access. That is to say, any future submodule

Re: [swift-evolution] [Proposal] Add clamp(to:) to the stdlib

Sorry did I skip a step in the proposal process? On Tue, Mar 21, 2017 at 7:09 PM, Nicholas Maccharoli wrote: > ​Swift-Evolution, > > I propose that `clamp(to:)` be added to the standard library as detailed > in the proposal written below. > There is also an open pull

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

Or, since many designs for submodules are possible... confident that there will be a good design for submodules We lack any real information on what Swift designs are possible.  We can look to other languages for inspiration but they cannot be transplanted wholesale into Swift from a technical,

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

I agree with everything you wrote here. And it is for that reason that I would expect that any future proposal for submodules should be judged in no small part on its _not_ changing circumstances surrounding access modifiers, such that no further proposals to revisit this topic will come up. It's

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

I didn’t even know the compiler still supported these implicit conversions. So, +1, I guess. Charles > On Mar 23, 2017, at 12:35 AM, Robert Widmann via swift-evolution > wrote: > > Good evening all, > > Attached is the proposal text that came out of a short

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

> On Mar 23, 2017, at 9:03 AM, Charlie Monroe wrote: > >> >> On Mar 23, 2017, at 9:44 AM, Slava Pestov > > wrote: >> >>> >>> On Mar 22, 2017, at 10:34 PM, Charlie Monroe via swift-evolution >>>

[swift-evolution] Pitch: Partial Implementations

MOTIVATION: In current Swift, a pattern has emerged among some developers, in order to logically group parts of a class or struct’s declaration, particularly around protocols: class Foo { … } extension Foo: SomeProtocol { ... } extension Foo: SomeOtherProtocol { ... }

Re: [swift-evolution] Pitch: Partial Implementations

> On Mar 23, 2017, at 1:12 PM, Charles Srstka via swift-evolution > wrote: > > MOTIVATION: > > In current Swift, a pattern has emerged among some developers, in order to > logically group parts of a class or struct’s declaration, particularly around > protocols: >

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

> On Mar 23, 2017, at 10:14 AM, Jordan Rose wrote: > >> >> On Mar 23, 2017, at 09:05, Joe Groff via swift-evolution >> > wrote: >> >> >>> On Mar 22, 2017, at 10:41 PM, Slava Pestov via swift-evolution >>>

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

What happens for people using @objc to choose the class's runtime name? It seems unfortunate to conflate that with changed inference. Jordan > On Mar 23, 2017, at 02:11, Slava Pestov via swift-evolution > wrote: > > A further benefit of this scheme is that it

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

> On Mar 23, 2017, at 01:46, Slava Pestov wrote: > > >> On Mar 22, 2017, at 5:51 PM, Jordan Rose via swift-evolution >> wrote: >> >> [Proposal: >> https://github.com/apple/swift-evolution/blob/master/proposals/0160-objc-inference.md] >> >> I'm

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

> I can't go into detail in public, but I can say that we did a postmortem on a > large lost sale and the customer specifically cited the number of frameworks > in our product as an integration barrier for them. Most iOS SDKs are > distributed as a single framework and so with that backdrop

Re: [swift-evolution] Overriding specific methods when adopting protocols with extension

Hey Iman, This is a known bug SR-103. It certainly has caught a few people off guard. Dale Buckley is working on an evolution proposal that would allow the bug to be fixed: Proposal: https://gist.github.com/dlbuckley/1858a7c0b5c027248fe16171d23ba01d Conversation on the Proposal:

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

> What is your evaluation of the proposal? -1. Plenty of excellent points are made in the threads, which clearly shows that there are many users who want to use the file based private feature only, and many users who want to keep everything _really_ private, unless they need to be exposed at a

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

> On Mar 23, 2017, at 09:05, Joe Groff via swift-evolution > wrote: > > >> On Mar 22, 2017, at 10:41 PM, Slava Pestov via swift-evolution >> > wrote: >> >> >>> On Mar 22, 2017, at 10:35 PM, Robert

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

To what extent could your need for safety be satisfied by (a) giving the property a long, unique name like `unsafeUnsynchronizedT`, and (b) writing a very small unit test/shell script/Perl script which makes sure references to that very unique name only appear between the two "MARK:" comments?

Re: [swift-evolution] Smart KeyPaths

> I guess I just don't understand why people seem so eager to change this > syntax. The biggest complaint seems to be that it's too lightweight and > natural; they're worried they might not realize they're using this big, scary > new feature. But this feature simply *isn't* big and scary! It's

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

> On Mar 23, 2017, at 1:22 AM, Matt Gallagher via swift-evolution > wrote: > >> What is your evaluation of the proposal? > > I disagree with this proposal. It removes functionality that I actively use. > > This proposal aims to revert SE-0025 without really

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

Like everyone I’m excited by this new proposal. But… > protocol Codable: Adopted by types to opt into archival. Conformance may be > automatically derived in cases where all properties are also Codable. … can I make one suggestion. Please do not repeat the mistakes of NSCoding in combining

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

> On 23 Mar 2017, at 05:18, Nevin Brackett-Rozinsky via swift-evolution > wrote: > 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”

[swift-evolution] Overriding specific methods when adopting protocols with extension

Hi, This is my first contribution to this list so I’m a little nervous. I’ve been refactoring some code in one of our internal frameworks and noticed something I didn’t noticed about protocols before. Maybe I’m missing the big picture here but I’ll expose the issue to you anyway. Consider

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

On March 23, 2017 at 2:22:20 AM, David Hart (da...@hartbit.com) wrote: > We will get static linking at some point in the near future. Static linking does not fix this issue. Just change "framework" to ".a". > If we wait until we get submodules, we won't be able to revisit. This is > probably

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

> On Mar 23, 2017, at 9:44 AM, Slava Pestov wrote: > >> >> On Mar 22, 2017, at 10:34 PM, Charlie Monroe via swift-evolution >> > wrote: >> >>> >>> On Mar 23, 2017, at 12:02 AM, Douglas Gregor via swift-evolution

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

Hi Oliver, Thanks for your comments! We thought about this and we agree overall — we will incorporate this suggestion along with others in the next batch update as long as nothing prohibitive comes up. — Itai On 23 Mar 2017, at 7:49, Oliver Jones wrote: Like everyone I’m excited by this

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

> On Mar 23, 2017, at 10:51 AM, Andrey Fidrya via swift-evolution > wrote: > >> On 23 Mar 2017, at 05:18, Nevin Brackett-Rozinsky via swift-evolution >> wrote: >> I strongly prefer that “private” should mean “visible in the current file”.

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

> On Mar 23, 2017, at 2:22 AM, Matt Gallagher via swift-evolution > wrote: > I can't help but feel that this proposal is really misdirected frustration. > Programmers who don't use clusters of tiny types in a single file shouldn't > care about the existence of a

Re: [swift-evolution] Swift null safety questions

> On Mar 22, 2017, at 7:25 PM, Elijah Johnson wrote: > > 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: >> >

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

> On Mar 23, 2017, at 10:54 AM, Zach Waldowski via swift-evolution > wrote: > > >> On Mar 23, 2017, at 2:22 AM, Matt Gallagher via swift-evolution >> > wrote: >> I can't help but feel that this proposal

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

> On Mar 22, 2017, at 10:41 PM, 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] Pitch: Partial Implementations

> On Mar 23, 2017, at 2:04 PM, Charles Srstka wrote: > >> On Mar 23, 2017, at 1:21 PM, Matthew Johnson > > wrote: >> >> If we wanted to allow code like this to be written we wouldn’t need a new >> keyword to do

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

> On Mar 23, 2017, at 2:02 PM, David Hart via swift-evolution > wrote: > > > > On 23 Mar 2017, at 16:49, Drew Crawford > wrote: > >> >> >> >> On March 23, 2017 at 2:22:20 AM, David Hart

Re: [swift-evolution] Pitch: Partial Implementations

> On Mar 23, 2017, at 2:15 PM, Matthew Johnson wrote: > > What I’m suggesting is that we could accomplish the same functionality by > enhancing extensions. You can make a case that using a different keyword for > same-module extensions that are allowed to have stored

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

> On 22 Mar 2017, at 17:41, Itai Ferber wrote: > > What’s the use case that you were thinking of? KeyPaths could be useful in > the case where you don’t need to customize your key names, but cannot > represent a custom case like > > public struct Post { > var authorID: Int > var

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

> On 21 Mar 2017, at 08:05, Rien wrote: > > +1 -1: I have revised my opinion. > >> • What is your evaluation of the proposal? > > Makes the language easier to understand, lowers cognitive load during coding. > I also hope this will pave the way for a overhaul of

Re: [swift-evolution] Pitch: Partial Implementations

I think the access levels should be revised, no need to introduce a new concept. Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github: http://github.com/Balancingrock Project: http://swiftfire.nl > On 23 Mar 2017, at 19:12, Charles Srstka via

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

Hi Oliver, > On Mar 23, 2017, at 7:55 AM, Oliver Jones via swift-evolution > wrote: > > Like everyone I’m excited by this new proposal. But… > > > protocol Codable: Adopted by types to opt into archival. Conformance may be > > automatically derived in cases where

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

> Le 23 mars 2017 à 12:03, Matthew Johnson via swift-evolution > a écrit : > > I think it’s likely that a non-trivial degree of any confusion is related to > the mistake we made in choosing the names. Both `fileprivate` and `private` > include the word `private` in

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

> On 23 Mar 2017, at 16:49, Drew Crawford wrote: > > > > >> On March 23, 2017 at 2:22:20 AM, David Hart (da...@hartbit.com) wrote: >> >> > We will get static linking at some point in the near future. > > Static linking does not fix this issue. Just change

Re: [swift-evolution] Pitch: Partial Implementations

> On Mar 23, 2017, at 1:21 PM, Matthew Johnson wrote: > > If we wanted to allow code like this to be written we wouldn’t need a new > keyword to do it. You are proposing two things here: > > 1) Allow stored properties in same-module extensions. This has been >

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

> What is your evaluation of the proposal? I disagree with this proposal. It removes functionality that I actively use. This proposal aims to revert SE-0025 without really addressing the aims of that proposal, merely dismissing the result as "actively harmful" without defining what that means.