Re: [swift-evolution] JSONEncoder: Key strategies

Yeha the API surface is a good concern. I was wondering if it would make sense to be part of String for example instead of tying it to the encoders api. I guess add that point it will be a different discussion. In any case, good proposal ;) Sent from my iPad > On 7 Nov 2017, at 00:35, Tony Park

Re: [swift-evolution] Pitch: Remove default initialization of optional bindings

I used the existence of the first one in my explanation of explain optionals. "There is a reasonable default value for an optional type. 'nothing'." TJ On Mon, Nov 6, 2017 at 6:52 PM, Slava Pestov via swift-evolution < swift-evolution@swift.org> wrote: > > > On Nov 6, 2017, at 4:29 PM, Kelvin Ma

Re: [swift-evolution] Revisiting SE-0132 Rationalizing Sequence end-operation names

+1 here, this irked me for a while as well. On Mon, Nov 6, 2017 at 10:05 AM, Rudolf Adamkovič via swift-evolution < swift-evolution@swift.org> wrote: > Huge +1. Every time I work with collections, I read the type signatures to > be 100% on whether a method will mutate in place or not. I don’t tru

Re: [swift-evolution] Pitch: Remove default initialization of optional bindings

> On Nov 6, 2017, at 4:29 PM, Kelvin Ma wrote: > > hot take: i use the second one a lot but only because i always forget the > first one exists. So I type the = nil just to “be sure”. Yeah, that’s one of my arguments against having the feature, along with the simple fact that if the language

Re: [swift-evolution] JSONEncoder: Key strategies

Hi Tony, Is it better for us to choose on `Codable` side whether `rawValue` of `CodingKeys` should be generated with snake_case? It seems to be more consistent with the current method of setting `rawValue` of `CodingKeys` on `Codable` side. Thanks, -- @norio_nomura 2017-11-07 5:54 GMT+09:00 Tony

Re: [swift-evolution] Pitch: Remove default initialization of optional bindings

> On Nov 6, 2017, at 5:29 PM, Kelvin Ma via swift-evolution > wrote: > > hot take: i use the second one a lot but only because i always forget the > first one exists. So I type the = nil just to “be sure”. > Same here! I just changed a bunch of code since I’d forgotten they were the same >

Re: [swift-evolution] JSONEncoder: Key strategies

Hi Alejandro, > On Nov 6, 2017, at 3:14 PM, Alejandro Martinez via swift-evolution > wrote: > > I’m in favor of this as it’s really, but specially the custom strategy. And > thinking about that, would there be a way to expose the functionality of > converting a string to camel case or snake c

Re: [swift-evolution] Pitch: Remove default initialization of optional bindings

hot take: i use the second one a lot but only because i always forget the first one exists. So I type the = nil just to “be sure”. On Mon, Nov 6, 2017 at 4:33 PM, Slava Pestov via swift-evolution < swift-evolution@swift.org> wrote: > Hi all, > > Right now, the following two declarations are equiv

Re: [swift-evolution] Pitch: Remove default initialization of optional bindings

It sounds like several people rely on this behavior and are actually aware that it exists, so I won’t pursue the issue further. Thanks for the feedback! > On Nov 6, 2017, at 3:07 PM, Alejandro Martinez wrote: > > I won’t complain a lot if it’s decided to be removed but I would prefer it to >

Re: [swift-evolution] JSONEncoder: Key strategies

I’m in favor of this as it’s really, but specially the custom strategy. And thinking about that, would there be a way to expose the functionality of converting a string to camel case or snake case so it could be used in case of writing a custom strategy. Would be cool to have the original functi

Re: [swift-evolution] Pitch: Remove default initialization of optional bindings

I won’t complain a lot if it’s decided to be removed but I would prefer it to stay. I use it constantly. Sent from my iPad > On 6 Nov 2017, at 22:41, Jon Shier via swift-evolution > wrote: > >I use this on all of my mutable optional properties, when I have to use > them. It’s just that l

Re: [swift-evolution] Pitch: Remove default initialization of optional bindings

I use this on all of my mutable optional properties, when I have to use them. It’s just that little extra bit of code I don’t need to write, and it feels a lot like parameter defaults in use. By surface area, I assume you mean the fact that it’s an implicit behavior people may need to re

Re: [swift-evolution] Pitch: Remove default initialization of optional bindings

> On Nov 6, 2017, at 4:33 PM, Slava Pestov via swift-evolution > wrote: > > Hi all, > > Right now, the following two declarations are equivalent: > > struct S { > var x: Int? > } > > struct S { > var x: Int? = nil > } > > That is, mutable bindings of sugared optional type (but not Optiona

Re: [swift-evolution] Pitch: Remove default initialization of optional bindings

Just a quick question for clarification. What will happen to these? Do we have to provide the default value ourselves? class ViewController : UIViewController {     @IBOutlet weak var view1: UIView?     @IBOutlet weak var view2: UIView! } Am 6. November 2017 um 23:33:51, Slava Pestov via swif

[swift-evolution] Pitch: Remove default initialization of optional bindings

Hi all, Right now, the following two declarations are equivalent: struct S { var x: Int? } struct S { var x: Int? = nil } That is, mutable bindings of sugared optional type (but not Optional!) always have a default value of ‘nil’. This feature increases the surface area of the language fo

[swift-evolution] JSONEncoder: Key strategies

Hi everyone, While we have no formal process at this time for proposals of changes to Foundation-only code, I would still like to post one that we have run through our internal process here for additional public comment. Link to PR with proposal content: https://github.com/apple/swift-corelibs

Re: [swift-evolution] [SPM] Roadmap?

On Mon, Nov 6, 2017 at 1:00 PM, Rick Ballard via swift-evolution < swift-evolution@swift.org> wrote: > > On Oct 23, 2017, at 10:41 AM, Jean-Christophe Pastant via swift-evolution < > swift-evolution@swift.org> wrote: > > Hi, > > Is there any news about features that are willling to be integrated i

Re: [swift-evolution] Abstract methods

On 6 November 2017 at 19:44, Tino Heth <2...@gmx.de> wrote: > to me protocol extensions are both cool and evil. cool as you can add > code. evil because it's more natural to add another declarations in those > extensions rather than implementation: > > protocol Foo { > func foo() > } > > exten

Re: [swift-evolution] Abstract methods

> to me protocol extensions are both cool and evil. cool as you can add code. > evil because it's more natural to add another declarations in those > extensions rather than implementation: > > protocol Foo { > func foo() > } > > extension Foo { >func bar()//*** natural assumption is

Re: [swift-evolution] Abstract methods

> to me protocol extensions are both cool and evil. cool as you can add code. > evil because it's more natural to add another declarations in those > extensions rather than implementation: > > protocol Foo { >func foo() > } > > extension Foo { > func bar()//*** natural assumption is tha

Re: [swift-evolution] PITCH: Export _JSONEncoder / _JSONDecoder

Hi Florent, We definitely thought about this while designing the set of types with the Codable proposals. One serious concern was just how much API surface area there already is with Codable. If we open up the internal classes as well, we risk confusing the majority of people who are just adop

Re: [swift-evolution] [SPM] Roadmap?

> On Oct 23, 2017, at 10:41 AM, Jean-Christophe Pastant via swift-evolution > wrote: > > Hi, > > Is there any news about features that are willling to be integrated into SPM > 5? > Those I see the most relevant: > - iOS support > - Some kind of configuration/settings support (debug, release,

Re: [swift-evolution] Abstract methods

on Sun, 5 Nov 2017 09:27:09 + Goffredo Marocchi wrote: > > I would say that you kind of already entered a slippery slope when the > extension to a protocol can add code / not just declare a behavioural > contract ... to me protocol extensions are both cool and evil. cool as you can add code

Re: [swift-evolution] Re-pitch: Deriving collections of enum cases

On Sun, Nov 5, 2017 at 11:54 PM Jacob Bandes-Storch via swift-evolution < swift-evolution@swift.org> wrote: > Over a year ago, we discussed adding a magic "allValues"/"allCases" static > property on enums with a compiler-derived implementation. The original > proposal > PR