Re: [swift-evolution] Enhancing access levels without breaking changes

Sent from my iPhone > On 11 Apr 2017, at 01:37, Ricardo Parada via swift-evolution > wrote: > > I have not voted in favor or against the proposal. I have been reading a lot > of responses but I agree with Tony. > > When I started reading the proposal everything

Re: [swift-evolution] Proposal: Split extensions into implementing methods and adding static functions Was: [swift-evolution-announce] [Review] SE-0164: Remove final support in protocol extensions

As far as I'm aware, eliminating retroactive conformances is a non-starter. On Mon, Apr 10, 2017 at 21:44 Howard Lovatt wrote: > @Xiaodi, > > You make two drugs. > > 1. Deliberately making retroactive conformance outside of the file in > which the type is declared

Re: [swift-evolution] Proposal: Split extensions into implementing methods and adding static functions Was: [swift-evolution-announce] [Review] SE-0164: Remove final support in protocol extensions

@Xiaodi, You make two drugs. 1. Deliberately making retroactive conformance outside of the file in which the type is declared illegal because of the problems it causes. See all the questions on Swift Users and watch people learning Swift get caught out. 2. Outside of the file in which the

[swift-evolution] SE-0169

All - I am not in favor of this change. While I agree that the implementation of fileprivate and open as well as the changes to private had some unintended by-products, they can easily be accommodated. Sometimes the language by its nature dictates style. I say at this point, we all just

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

+0.5 Positive on multi-line string literal Negative on the delimiter. I don’t like continuation character, but would like to have something similar to classic C comments: distinct, symmetrical opening and closing delimiters. But I don’t have any specific suggestion. > On Apr 7, 2017, at

Re: [swift-evolution] SE-163: String Revision: Collection Conformance, C Interop, Transcoding

+1 with this clarification / revision > On Apr 6, 2017, at 5:34 PM, Ben Cohen via swift-evolution > wrote: > > >> On Apr 5, 2017, at 10:32 PM, Félix Cloutier > > wrote: >> >> During the proposal phase, we asked how

Re: [swift-evolution] [Returned for revision] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

+1 Having the feature is worth the oddities of the syntax. > On Apr 5, 2017, at 4:01 PM, Douglas Gregor via swift-evolution > wrote: > > Proposal Link: > https://github.com/apple/swift-evolution/blob/master/proposals/0161-key-paths.md > >

Re: [swift-evolution] [Review] SE-0164: Remove final support in protocol extensions

Agreed. +1 > On Apr 6, 2017, at 11:51 AM, Jordan Rose via swift-evolution > wrote: > > [Proposal: > https://github.com/apple/swift-evolution/blob/master/proposals/0164-remove-final-support-in-protocol-extensions.md > >

Re: [swift-evolution] [Review] SE-0166: Swift Archival & Serialization

How exactly does that work from the perspective of the initializer if you have 2 sets of keys to choose from? Would I extend the initializer to include my feature flag `public init(from decoder: Decoder, flag: Bool) throws` and switch on that? Or could I pass in the Container I want to use

Re: [swift-evolution] Enhancing access levels without breaking changes

I have not voted in favor or against the proposal. I have been reading a lot of responses but I agree with Tony. When I started reading the proposal everything was more or less fine half way through the proposal because it was reverting private to fileprivate between the type and its

[swift-evolution] [Pitch] Remove type-inference for stored property

This seems like something a linter should handle. > Hi all, > > In a discussion about inferring parameter types from default value, Slava > brought up some performance problems caused by type inference for stored > properties in side types: > >

[swift-evolution] [Review] SE-0168: Multi-Line String Literals

> Hello Swift community, > > The review of SE-0168 "Multi-Line String Literals" begins now and runs > through April 12, 2017. The proposal is available here: > > https://github.com/apple/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md > > Reviews are an important part

[swift-evolution] SE-165: Dictionary & Set Enhancements

> Hello, Swift community! > > The review of "SE-165: Dictionary Enhancements" begins now and runs > through next Tuesday, April 11th. The proposal is available here: >

Re: [swift-evolution] Proposal: Split extensions into implementing methods and adding static functions Was: [swift-evolution-announce] [Review] SE-0164: Remove final support in protocol extensions

On Mon, Apr 10, 2017 at 5:35 PM, Howard Lovatt via swift-evolution < swift-evolution@swift.org> wrote: > In response to Jordan Rose's comment I suggest the following change: > > Proposal: Split extension usage up into implementing methods and adding > static functions > > > Currently extension

[swift-evolution] Proposal: Split extensions into implementing methods and adding static functions Was: [swift-evolution-announce] [Review] SE-0164: Remove final support in protocol extensions

In response to Jordan Rose's comment I suggest the following change: Proposal: Split extension usage up into implementing methods and adding static functions Currently extension methods are confusing because they have different dispatch rules for the same syntax. EG: protocol P {

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0166: Swift Archival & Serialization

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0166-swift-archival-serialization.md I'm a +1 on the proposal, I just have a few small questions and suggestions after giving it a brief read. 1) I'm not thrilled about the name "unkeyedContainer()" and related names.

Re: [swift-evolution] [Review] SE-0166: Swift Archival & Serialization

Hi Rex, > On Apr 10, 2017, at 12:48 PM, Rex Fenley via swift-evolution > wrote: > > Forgive me if I'm missing something, this is a very large proposal and a lot > to parse through. I like how everything is designed as far as I can tell > except I'm not sure from

Re: [swift-evolution] [Review] SE-0167: Swift Encoders

[Proposal: https://github.com/apple/swift-evolution/blob/master/proposals/0167-swift-encoders.md ] There's some pretty cool stuff in here. Nice work. I do have a few questions about this design, though: -

Re: [swift-evolution] [Review] SE-0167: Swift Encoders

> On Apr 10, 2017, at 3:47 PM, Jordan Rose via swift-evolution > wrote: > > >> On Apr 10, 2017, at 02:52, David Hart via swift-evolution >> > wrote: >> >>> >>> On 10 Apr 2017, at 11:36, piotr gorzelany

Re: [swift-evolution] [Review] SE-0167: Swift Encoders

> On Apr 10, 2017, at 02:52, David Hart via swift-evolution > wrote: > >> >> On 10 Apr 2017, at 11:36, piotr gorzelany via swift-evolution >> > wrote: >> >> This is a really great proposal. As an iOS

Re: [swift-evolution] [Review] SE-0166: Swift Archival & Serialization

Forgive me if I'm missing something, this is a very large proposal and a lot to parse through. I like how everything is designed as far as I can tell except I'm not sure from this proposal how one would compose multiple different types of Decoders against the same output type. For example, with

Re: [swift-evolution] [pitch] Adding in-place removeAll to the std lib

array.remove(where: { $0 > 3 }) array.remove { $0 > 3 } > On Apr 10, 2017, at 12:25 PM, David Hart via swift-evolution > wrote: > > > > On 10 Apr 2017, at 17:17, Maximilian Hünenberger via swift-evolution >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

> On Apr 8, 2017, at 4:12 PM, Xiaodi Wu wrote: > > On Fri, Apr 7, 2017 at 11:34 PM, John McCall via swift-evolution > > wrote: > > > On Apr 7, 2017, at 8:12 PM, Jakub Suder via swift-evolution > >

Re: [swift-evolution] [pitch] Adding in-place removeAll to the std lib

> On 10 Apr 2017, at 17:17, Maximilian Hünenberger via swift-evolution > wrote: > > How about this: > > array.removeEvery(3) > array.removeEvery{ $0 > 3 } > > I think it preserves the meaning while it reads nicely. However "every" has > no precedent in

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

> On Apr 10, 2017, at 1:04 PM, Daniel Duan wrote: > >> >> On Apr 10, 2017, at 10:52 AM, Matthew Johnson wrote: >> >> >>> On Apr 10, 2017, at 12:48 PM, Daniel Duan wrote: >>> >>> No offense taken. >>> >>> There's no inherent

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

> On Apr 10, 2017, at 10:52 AM, Matthew Johnson wrote: > > >> On Apr 10, 2017, at 12:48 PM, Daniel Duan wrote: >> >> No offense taken. >> >> There's no inherent problem with designing language with available tools in >> mind. After all, what we put

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

> On Apr 10, 2017, at 12:48 PM, Daniel Duan wrote: > > No offense taken. > > There's no inherent problem with designing language with available tools in > mind. After all, what we put in the language is a strict subset of what's > viable in a compiler. > > IMHO Swift

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

No offense taken. There's no inherent problem with designing language with available tools in mind. After all, what we put in the language is a strict subset of what's viable in a compiler. IMHO Swift should care more about separation of language and tools due to its long-term ambition: is

Re: [swift-evolution] Enhancing access levels without breaking changes

On Mon, Apr 10, 2017 at 9:49 AM Tino Heth <2...@gmx.de> wrote: > But even outside the generated code use cases, it's nice to just be able > to implement helpers or additional "convenience" conformances in separate > files named appropriately (like "Type+Protocol.swift" or > "Type+Helpers.swift").

Re: [swift-evolution] Enhancing access levels without breaking changes

> On Apr 10, 2017, at 10:22 AM, Tino Heth <2...@gmx.de> wrote: > > >>> I don't buy this argument at all without an objective explanation why the >>> curly braces of extensions should be treated different than the curly >>> braces of types… >> Extensions are not Partials. >>> do you think

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

> On Apr 10, 2017, at 7:22 PM, Sean Heber via swift-evolution > wrote: > > >> On Apr 10, 2017, at 11:38 AM, Daniel Duan wrote: >> >> Using tools isn't a bad thing. Designing language assuming users are using >> tools with certain capability is

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

> On Apr 10, 2017, at 11:38 AM, Daniel Duan wrote: > > Using tools isn't a bad thing. Designing language assuming users are using > tools with certain capability is kind of a bad thing. I see this sentiment on this list a lot. Where does it come from? Is there any supporting

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

> On Apr 7, 2017, at 12:21 AM, Daniel Duan via swift-evolution > wrote: > > Hi all, > > In a discussion about inferring parameter types from default value, Slava > brought up some performance problems caused by type inference for stored > properties in side types:

Re: [swift-evolution] Enhancing access levels without breaking changes

>> I don't buy this argument at all without an objective explanation why the >> curly braces of extensions should be treated different than the curly braces >> of types… > Extensions are not Partials. >> do you think sprinkling parts of class over the project is easier to follow? > Extensions

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

That's kind of my perspective too. Personally I adore this feature. But compiling speed is such a severe issue at work that I'm willing to part with it. (Not saying other arguments aren't important). I'm lucky enough to work on a project that is: 1. purely Swift 2. Vigilantly monitored for

Re: [swift-evolution] [Proposal] Foundation Swift Encoders

https://github.com/apple/swift-evolution/blob/master/proposals/0167-swift-encoders.md This is a really great proposal. As an iOS developer I work with JSON almost every day since most mobile apps communicate with a backend through JSON messages. It's good to see that better JSON support is coming

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0166: Swift Archival & Serialization

Hi! To begin with, I have three questions: 1. Are these proposals purely meant for archival or do they also aim to be the basis of an optimal solution for decoding/unmarshalling JSON from external APIs? 2. How are Optionals of Codable types handled? I see no mentions of this. Do they map to

Re: [swift-evolution] switch must be exhaustive, consider adding a default clause

On Apr 10, 2017, at 9:53 AM, Kevin Nattinger > wrote: On Apr 10, 2017, at 9:18 AM, Josh Parmenter via swift-evolution > wrote: case .none isn’t handled. It shouldn’t need to be

Re: [swift-evolution] Enhancing access levels without breaking changes

> On Apr 10, 2017, at 9:49 AM, Tino Heth via swift-evolution > wrote: > >> But even outside the generated code use cases, it's nice to just be able to >> implement helpers or additional "convenience" conformances in separate files >> named appropriately (like

Re: [swift-evolution] switch must be exhaustive, consider adding a default clause

> On Apr 10, 2017, at 9:18 AM, Josh Parmenter via swift-evolution > wrote: > > case .none isn’t handled. It shouldn’t need to be handled in the second switch because it’s impossible. Not just developer thinks “impossible” but easily provable by static analysis the

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

> On Apr 10, 2017, at 11:38 AM, Daniel Duan wrote: > > Using tools isn't a bad thing. Designing language assuming users are using > tools with certain capability is kind of a bad thing. > > Where tools *can* help is if the tools enhance the language user's > experience,

Re: [swift-evolution] Enhancing access levels without breaking changes

> But even outside the generated code use cases, it's nice to just be able to > implement helpers or additional "convenience" conformances in separate files > named appropriately (like "Type+Protocol.swift" or "Type+Helpers.swift"). I > find it makes my codebase easier to navigate. No doubt

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

Using tools isn't a bad thing. Designing language assuming users are using tools with certain capability is kind of a bad thing. Where tools *can* help is if the tools enhance the language user's experience, which is why I proposed the inference capabilities be kept for diagnostics. I also

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

> On Apr 10, 2017, at 11:22 AM, Daniel Duan wrote: > > I guess I'm using the word "export" loosely. Often times I find myself > reading type signatures in my own codebase either because it's written by > someone else on my team or by myself long time ago. I think open-source

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

I guess I'm using the word "export" loosely. Often times I find myself reading type signatures in my own codebase either because it's written by someone else on my team or by myself long time ago. I think open-source library users have the same problem. Exposure to a particular local variable

Re: [swift-evolution] switch must be exhaustive, consider adding a default clause

case .none isn’t handled. This should probably be on the swift-users list though, no? Best, Josh On Apr 8, 2017, at 11:29 AM, Drew Crawford via swift-evolution > wrote: Is there a good reason we do not compile this: import UIKit

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

> On Apr 10, 2017, at 11:11 AM, Daniel Duan via swift-evolution > wrote: > > I’m not questioning the value of type inference in general. Just that there > are practical implications when we want more of them. There’s a difference in > inferencing type declaration

[swift-evolution] switch must be exhaustive, consider adding a default clause

Is there a good reason we do not compile this: import UIKit func foo(operation: UINavigationControllerOperation) {     switch(operation) {     case .push: /* snip */ break     case .pop: /* snip */ break     default:         preconditionFailure("This is a silly operation")     }    

[swift-evolution] [Pitch] Remove type-inference for stored property

Off the top of my head I’m not sure if there is a precedent for such a drastic change in behaviour between playgrounds and non-playground compilation. However, allowing type inference in playgrounds while disallowing this otherwise could maintain the benefits for educational and experimental

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

I’m not questioning the value of type inference in general. Just that there are practical implications when we want more of them. There’s a difference in inferencing type declaration properties and local variables: the former is more likely to be exported and read by others. These arguments are

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

Well, I’m not really a beginner, but for me personally, the computer is here to help me do my work and to do some of the thinking for me. I really hate repeating myself when it comes to types - especially if the types get wordy (collections, etc). Swift is pretty good about it - but these warts

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

It is helpful in the sense that it tells us what’s really inconsistent: beginner’s have to learn when inference is available when declaring their types. That’s story is sketchy. > On Apr 10, 2017, at 8:55 AM, Sean Heber wrote: > > This is not really a helpful comment, but: I

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

This is not really a helpful comment, but: I kinda wish they did. l8r Sean > On Apr 10, 2017, at 10:54 AM, Daniel Duan via swift-evolution > wrote: > > Neither of these works btw. > > func bar(myString = “hello”) > class Baz { > let myString = { return “hello”

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

Neither of these works btw. func bar(myString = “hello”) class Baz { let myString = { return “hello” }() } > On Apr 9, 2017, at 11:26 PM, Jean-Daniel wrote: > > I’m full -1 on this one. It will make the language inconsistent. How do you > explain a new comer that type

Re: [swift-evolution] Enhancing access levels without breaking changes

> What do you think of `partial` types like C# but limited to a file? Well, imho it would be better than some alternatives, because it might lay the ground for something that is more useful than current same-file extensions, which offer no guarantee that the extension declaring the conformance

Re: [swift-evolution] Enhancing access levels without breaking changes

> On Apr 10, 2017, at 10:26 AM, Tino Heth via swift-evolution > wrote: > >> I’m not sure that this solves anything meaningful (whether in relation to >> SE-0169 or more generally), does it? What advantage does this provide over >> just declaring the protocol

Re: [swift-evolution] Enhancing access levels without breaking changes

> I’m not sure that this solves anything meaningful (whether in relation to > SE-0169 or more generally), does it? What advantage does this provide over > just declaring the protocol conformance and those methods as a direct part of > the parent type? This seems like it would just introduce

Re: [swift-evolution] [pitch] Adding in-place removeAll to the std lib

How about this: array.removeEvery(3) array.removeEvery{ $0 > 3 } I think it preserves the meaning while it reads nicely. However "every" has no precedent in other functions, as far as I know. > Am 10.04.2017 um 04:32 schrieb Ben Cohen via swift-evolution > :

Re: [swift-evolution] Enhancing access levels without breaking changes

> The one issue I see is sticking that public extension inside a private one. > I think you would have to mark ‘secret: Int’ as private instead of the > extension itself to allow the effect you are looking for… I didn't think that much while writing the example, but this one was actually on

Re: [swift-evolution] Enhancing access levels without breaking changes

Extensions can already do what partials would do, and more—Swift does not need two features that are almost the same but with subtle differences when it comes to the visibility of its members. That seems like something that will only cause confusion for users. Partials feel like trying to shoehorn

Re: [swift-evolution] Enhancing access levels without breaking changes

> On Apr 10, 2017, at 12:20 AM, David Hart via swift-evolution > wrote: > > >>> On 10 Apr 2017, at 08:21, Jean-Daniel wrote: >>> >>> >>> Le 10 avr. 2017 à 07:15, David Hart via swift-evolution >>> a écrit : >>>

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0166: Swift Archival & Serialization

Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0166-swift-archival-serialization.md I’m not giving a complete review here, but this proposal seems like a

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

> Am 09.04.2017 um 18:29 schrieb John Holdsworth : > > Hi, John here, the submitter of the proposal. > > First up, I must apologise for putting Brent on the spot when I resubmitted > this altered proposal from last year. That was my mistake. > > Second up, apologies

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

I think it would be good to clarify that there are two similar things we discuss in this proposal. This proposal is about a [(multi-line string) literal]. And there is also the [multi-line (string literal)]. These are two different things because (1) does add explicit escaping for some

Re: [swift-evolution] [Review] SE-0167: Swift Encoders

> On 10 Apr 2017, at 11:36, piotr gorzelany via swift-evolution > wrote: > > This is a really great proposal. As an iOS developer I work with JSON almost > every day since most mobile apps communicate with a backend through JSON > messages. It's good to see that

[swift-evolution] [Review] SE-0167: Swift Encoders

This is a really great proposal. As an iOS developer I work with JSON almost every day since most mobile apps communicate with a backend through JSON messages. It's good to see that better JSON support is coming to Foundation so we don't have to rely on third party libraries. That being said,

Re: [swift-evolution] [Review #2] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

> On 9 Apr 2017, at 19:36, Tino Heth via swift-evolution > wrote: > > -1: > Although prefix "\" is imho the nicest variation that has been officially > suggested for this feature (I still like infix ":" better; maybe I've been > using classic MacOS to long), there

[swift-evolution] [Pitch?] Add clamp(to:) to the stdlib

Swift-Evolution, I was wondering if there was still some support from the community for adding `clamped(to:)` extensions to `Strideable` and `Comparable` for clamping a value on a provided range. The proposal is detailed below, sorry if I skipped a step earlier. Also here is a link to the pull

Re: [swift-evolution] Enhancing access levels without breaking changes

> On 10 Apr 2017, at 08:21, Jean-Daniel wrote: > > >> Le 10 avr. 2017 à 07:15, David Hart via swift-evolution >> > a écrit : >> >> >> >> On 10 Apr 2017, at 05:08, Jose Cheyo Jimenez via swift-evolution >>

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

I’m full -1 on this one. It will make the language inconsistent. How do you explain a new comer that type inference work in some case, but not in other cases, while in both the compiler is completely capable to define the type. Why let myString = "hello" would be accepted but not class

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

Sorry, I realized I had a little more to say about this. > On Apr 9, 2017, at 8:46 PM, Félix Cloutier wrote: > > C# was able to eliminate the whole class of SQL injections by introducing a > convenient and powerful syntax for queries that is not string-based. I think > that

Re: [swift-evolution] Enhancing access levels without breaking changes

> Le 10 avr. 2017 à 07:15, David Hart via swift-evolution > a écrit : > > > > On 10 Apr 2017, at 05:08, Jose Cheyo Jimenez via swift-evolution > > wrote: > >> >>> On Apr 9, 2017, at 7:14 PM, Jonathan