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 >> mailto:swift-evolution@swift.org>> a écrit : >> >> >> >> On 10 Apr 2017, at 05:08, Jose Cheyo Jimenez via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >>> >

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

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 is no general agreement, and

[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, ther

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 better JSON support is coming

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 charact

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 if the proposal is rather v

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 fantast

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 : >>> >>> >>> >>> On 10 Apr 2017, at 05:08, Jose Cheyo Jimenez via swift-evoluti

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

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

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 > : > > >>> On Apr 8, 2017, a

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 more

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 conformance and those methods as a

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 a

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 inference work in some

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” }() > } > >> On Apr 9, 2017,

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 kinda wish they did

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

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

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

[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")     }     switch(oper

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 properties and 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 mailto:swift-evolution@swift.org>> wrote: Is there a good reason we do not compile this: import UIKit func foo(operation: UINaviga

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

On Mon, Apr 10, 2017 at 8:26 AM Tino Heth via swift-evolution < swift-evolution@swift.org> 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 conformance and t

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 is

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 > library users h

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 disa

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 abou

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, which is why I propose

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 compiler is doing it anyway

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 "Type+Protocol.swift" or "Type+He

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

On Apr 10, 2017, at 9:53 AM, Kevin Nattinger mailto:sw...@nattinger.net>> wrote: On Apr 10, 2017, at 9:18 AM, Josh Parmenter via swift-evolution mailto:swift-evolution@swift.org>> wrote: case .none isn’t handled. It shouldn’t need to be handled in the second switch because it’s impossible.

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 miss

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

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 a

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: > > https://lists.swift.or

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 research? What dr

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 kind of a bad thing. > > I see this sentiment

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 spri

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

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 should care more about

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 in the language is a strict subset of wha

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 problem with designing language with available tools in >>> min

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 other functions, as far as I k

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 > mailto:swift-evolution@swift.org>> wrote: > > > On Apr 7, 2017, at 8:12 PM, Jakub Suder via swift-evolution > > mailto:swift-evolution@swift.org>> wrote: > > > > > What is you

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 > mailto:swift-evolution@swift.org>> wrote: > >> How about this: >> >> array.remo

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 Loc

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 >> mailto:swift-evolution@swift.org>> wrote: >> >> This is a really great proposal. As an iOS developer I work with JSON almost >> every day since most

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 >> mailto:swift-evolution@swift.org>> wrote: >> >>> >>> On 10 Apr 2017, at 11:36, piotr gorzelany via swift-evolution >>> mailto:swift-evolution@swift.or

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

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 this proposal how one would co

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

[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 { f

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 met

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

> Hello, Swift community! > > The review of "SE-165: Dictionary&Set Enhancements" begins now and runs > through next Tuesday, April 11th. The proposal is available here: > https://github.com/apple/swift-evolution/blob/master/proposals/0165-dict.md

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

[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: > > https://lists.swift.org/pipermail/swift-evolution

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 extension

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 somehow,

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] [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] 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 this would handle fixed-length >> strings with an o

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

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

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 ty

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 illegal because of the problem

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 was more or less fine half

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

> On Apr 6, 2017, at 11:10 AM, Douglas Gregor wrote: > > Proposal link: > > https://github.com/apple/swift-evolution/blob/master/proposals/0166-swift-archival-serialization.md > > > What is y

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

-1 (strong) I think I've read all messages and haven't much to add — so just to sum up my concerns in order: — It makes access control more complicated For me, it's not about the complexity itself (it's not terrible huge, after all), but I believe in the beauty of simplicity, which is already qu