Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

> On Jan 6, 2016, at 5:08 PM, Joe Groff wrote: > > I find it surprising that you key the initialization of 'var's based on > whether their setter is visible or not. Initialization is not the same as > setting, and memberwise initializers within the definition have private >

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

Here is an expanded proposal for the syntax for a Scala style memberwise syntax and equivalent code, specification is via an example rather than formal syntax since this is easier to follow. Note it is like Scala’s syntax but it is ‘Swiftified” (in particular still retains `init` keyword).

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

> On Jan 6, 2016, at 6:31 PM, Matthew Johnson wrote: > > > > Sent from my iPad > >> On Jan 6, 2016, at 7:57 PM, Joe Groff wrote: >> >> >>> On Jan 6, 2016, at 3:39 PM, Matthew Johnson wrote: >>> >>> On Jan 6, 2016,

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

Yes I did mess up the translation, that will teach me to do it at night on an iPad (therefore no compiler). The correct translation is: Types and let's needed for example: public class SuperType { init(_: SPType) {} } public struct SPType {} public struct PPType {}

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

Sent from my iPad > On Jan 6, 2016, at 7:57 PM, Joe Groff wrote: > > >> On Jan 6, 2016, at 3:39 PM, Matthew Johnson wrote: >> >> >>> On Jan 6, 2016, at 5:08 PM, Joe Groff wrote: >>> >>> I find it surprising that you key the

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

> On Jan 6, 2016, at 3:39 PM, Matthew Johnson wrote: > > >> On Jan 6, 2016, at 5:08 PM, Joe Groff wrote: >> >> I find it surprising that you key the initialization of 'var's based on >> whether their setter is visible or not. Initialization is not

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

Sent from my iPad > On Jan 6, 2016, at 8:43 PM, Joe Groff wrote: > > >> On Jan 6, 2016, at 6:31 PM, Matthew Johnson wrote: >> >> >> >> Sent from my iPad >> On Jan 6, 2016, at 7:57 PM, Joe Groff wrote: > On

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

> On Jan 6, 2016, at 19:07 , Matthew Johnson via swift-evolution > wrote: > > > > Sent from my iPad > > On Jan 6, 2016, at 8:43 PM, Joe Groff > wrote: > >> >>> On Jan 6, 2016, at 6:31 PM, Matthew Johnson

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

> On Jan 6, 2016, at 4:52 PM, Howard Lovatt wrote: > > Here is an expanded proposal for the syntax for a Scala style memberwise > syntax and equivalent code, specification is via an example rather than > formal syntax since this is easier to follow. Note it is like

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

Hopefully this is still the right place to discuss this proposal (it's listed as being in active review , but I don't see a separate [Review] thread). I like this proposal. I think it will bring some much-needed ease-of-use. I'm

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

> On Jan 4, 2016, at 11:31 PM, Howard Lovatt wrote: > > I was guessing that the current proposal does not change anything re. default > and current member wise initializers and so in addition to suggesting Scala > syntax I was also suggesting the transformation shown,

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

> The “type parameter list” syntax is sugar that could be implemented as a > layer on top of the current proposal or could be implemented orthogonally. Hi Howard, I've heard this argument before, so I'll repeat my answer as well: Both offers don't make sense, it's either one way or the other (or

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

> On Jan 5, 2016, at 12:12 PM, Tino Heth <2...@gmx.de> wrote: > > >> The “type parameter list” syntax is sugar that could be implemented as a >> layer on top of the current proposal or could be implemented orthogonally. > Hi Howard, > I've heard this argument before, so I'll repeat my answer

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

Yes you can get close, but: 1. Its weird that you can only do this in an extension. 2. Its not quite the same as the proposal the current member-wise initialiser does not make the init arguments optional (the arguments themselves do not have defaults), i.e. with your example `let

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

> On Jan 4, 2016, at 5:48 PM, Howard Lovatt wrote: > > Yes you can get close, but: > > 1. Its weird that you can only do this in an extension. This is the way the current implicit initializer works. It is not synthesized if you define any initializers in the body of

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

I was guessing that the current proposal does not change anything re. default and current member wise initializers and so in addition to suggesting Scala syntax I was also suggesting the transformation shown, or its equivalent. The advantage of having a member wise init that has default arguments

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

> What are those advantages precisely? subjective: Easier to understand objective: Saves keywords/syntax ("…", "memberwise", "@nomemberwise", "required", "convenience", "@default"…) >> What I can see in your example is that the proposed syntax allows me to >> trigger compiler errors that

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

> On Jan 1, 2016, at 6:57 AM, Tino Heth <2...@gmx.de> wrote: > >>> I deny that, and even if it is true, there is a price to pay — and that is >>> more than the lines of code that are required… >> >> Personally, I think it is a lot more readable to put members separate lines, >> but if you

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

>> I deny that, and even if it is true, there is a price to pay — and that is >> more than the lines of code that are required… > > Personally, I think it is a lot more readable to put members separate lines, > but if you don’t like doing that: You are focusing on the least important thing here

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

> On Dec 31, 2015, at 5:44 AM, Tino Heth <2...@gmx.de> wrote: > > This is some sort of a cross-post from another thread ["automatic protocol > forwarding"] — for anyone who wants to follow, I recommend to read > https://kotlinlang.org/docs/reference/classes.html >

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

This is some sort of a cross-post from another thread ["automatic protocol forwarding"] — for anyone who wants to follow, I recommend to read https://kotlinlang.org/docs/reference/classes.html The idea of "function-like class declaration" has

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

> On Dec 28, 2015, at 12:59 PM, Joe Groff wrote: > >> >> On Dec 27, 2015, at 9:51 AM, Matthew Johnson via swift-evolution >> > wrote: >> >>> >>> On Dec 26, 2015, at 11:31 PM, Chris Lattner

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

> On Dec 27, 2015, at 9:51 AM, Matthew Johnson via swift-evolution > wrote: > >> >> On Dec 26, 2015, at 11:31 PM, Chris Lattner > > wrote: >> >> On Dec 25, 2015, at 12:04 PM, Matthew Johnson

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

> Sorry if this has been discussed and I missed it, but Scala and Kotlin both > support a compact function-like class declaration syntax for simple "case > classes". Just took some time to read more deeply and would have added a reference to Kotlin on my own — I think their approach of

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

> On Dec 24, 2015, at 10:42 PM, Chris Lattner wrote: > >> On Dec 23, 2015, at 9:25 AM, Matthew Johnson > > wrote: >>> >>> Hi Matthew, >>> >>> I continue to really like the approach and direction. Here’s an attempt

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

> On Dec 24, 2015, at 3:05 PM, Joe Groff wrote: > >> >> On Dec 24, 2015, at 12:17 PM, Matthew Johnson > > wrote: >> >>> >>> On Dec 24, 2015, at 11:11 AM, Joe Groff >> >

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

> On Dec 24, 2015, at 11:11 AM, Joe Groff wrote: > >> >> On Dec 24, 2015, at 5:41 AM, Matthew Johnson via swift-evolution >> > wrote: >> >> >> >> Sent from my iPad >> >>> On Dec 24, 2015, at 5:46 AM, Thorsten

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

Sent from my iPad > On Dec 24, 2015, at 5:46 AM, Thorsten Seitz wrote: > > >> Am 22.12.2015 um 18:30 schrieb Matthew Johnson : >> >> My proposal is specifically suggesting that we treat “initial value” as a >> default rather than an

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

> Why would you have an immutable instance member that is always going to have > a constant value of 1? That just wastes space by duplicating the constant > value in many instances. However it is quite reasonable to have an immutable > instance member that defaults to 1, but may have a

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

> On Dec 22, 2015, at 1:23 PM, Félix Cloutier wrote: > > I would like let rules to be consistent whether you have a memberwise init or > not; and I would like them to be consistent with classes. > The proposal recommended changing the rules everywhere so they would have

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

> On Dec 22, 2015, at 1:29 PM, Chris Lattner wrote: > > >> On Dec 22, 2015, at 8:46 AM, Matthew Johnson > > wrote: >> >> Hi Chris, >> >> I have given your feedback a lot of thought and have taken another run at

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

Properties with initial values struct S { let s: String = "hello" let i: Int = 42 // user declares: memberwise init() {} // compiler synthesizes: init(s: String = "hello", i: Int = 42) { self.s = s self.i = i } } I think the sticking issue here is

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

> On Dec 22, 2015, at 12:25 PM, David Owens II wrote: > > >> On Dec 22, 2015, at 10:15 AM, Chris Lattner > > wrote: >> >> We would like to integrate this into the package manager as well, so it >> helps “enforce” proper

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

> On Dec 22, 2015, at 12:51 PM, Guillaume Lessard via swift-evolution > wrote: > > Hi, > > Regardless of anything else in the proposal, I strongly dislike its attempted > subversion of `let` properties. > > struct A { > let member = 1 // It’s done, over. If

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

> On Dec 22, 2015, at 8:46 AM, Matthew Johnson wrote: > > Hi Chris, > > I have given your feedback a lot of thought and have taken another run at > this proposal from a slightly different angle. I believe it is a significant > improvement. Hi Matthew, I continue

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

> On Dec 22, 2015, at 9:59 AM, David Owens II wrote: > > >> On Dec 22, 2015, at 9:43 AM, Matthew Johnson wrote: >> >> Adding a new member to a struct is itself a breaking change. I don’t see >> how memberwise initialization makes this worse. > > It

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

> On 22 déc. 2015, at 12:02, Matthew Johnson wrote: > > This is not an attempt to subvert `let` properties. The `= 1` in the > declaration can very reasonably be viewed as a default value that should be > used if the member is not otherwise initialized. I see it as a

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

(adding on) > On 22 déc. 2015, at 12:02, Matthew Johnson wrote: > > Why would you have an immutable instance member that is always going to have > a constant value of 1? That’s obviously a toy example. You can also use function calls, and that’s useful: public struct

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

> On Dec 21, 2015, at 11:05 PM, Brent Royal-Gordon via swift-evolution > wrote: > >>> The proposal already states that a memberwise initializer only includes >>> parameters for properties that are at least as visible as the initializer >>> itself. So if you can see

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

Hi Chris, I have given your feedback a lot of thought and have taken another run at this proposal from a slightly different angle. I believe it is a significant improvement. I believe the programmer model is now very clear straightforward: The set of properties that receive memberwise

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

> On Dec 22, 2015, at 12:59 AM, David Owens II wrote: > > >> On Dec 21, 2015, at 10:39 PM, Brent Royal-Gordon >> wrote: >> >>> Also, I don’t think it generates good API signatures. Take this example: >>> >>> struct S { >>> let s: String >>>

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

> On Dec 22, 2015, at 12:08 AM, David Owens II wrote: > > I really like the idea and it’s something that’s extremely annoying to deal > with today in Swift. My biggest concern is that the proposal, in its > entirety, seems to really complicate the initialization rules. Hi

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

Thanks for responding Brent. I agree with all of your comments. > On Dec 22, 2015, at 12:39 AM, Brent Royal-Gordon > wrote: > >> Also, I don’t think it generates good API signatures. Take this example: >> >> struct S { >> let s: String >> let i: Int >> >>

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

> On Dec 22, 2015, at 11:22 AM, Thorsten Seitz wrote: > > >> Am 22.12.2015 um 05:43 schrieb Matthew Johnson via swift-evolution >> : >> >> What do you think the downsides are of synthesizing memberwise >> initialization for properties with an

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

> Am 22.12.2015 um 05:43 schrieb Matthew Johnson via swift-evolution > : > > What do you think the downsides are of synthesizing memberwise initialization > for properties with an “initial value”? When using the memberwise initializer those properties are always

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

> On Dec 22, 2015, at 11:26 AM, David Owens II wrote: > > How are you going to deal with public properties creating a breaking change > in the memberwise init()? > > Example: > > v1.0 of the API ships: > > struct Person { > let name: String > } > > v1.1 of the API

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

> On Dec 21, 2015, at 8:12 PM, Brent Royal-Gordon > wrote: > >> This example is introducing two things: convenience inits, but also >> parameter arguments. For the sake of the proposal, I’d suggest splitting >> the parameter arguments out to its own discussion. It

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

> On Dec 21, 2015, at 5:47 PM, Chris Lattner via swift-evolution > wrote: > > On Dec 21, 2015, at 11:32 AM, Matthew Johnson via swift-evolution > > wrote: >> I have completed a draft of the proposal I have

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

> On Dec 21, 2015, at 11:05 PM, Brent Royal-Gordon > wrote: > >>> The proposal already states that a memberwise initializer only includes >>> parameters for properties that are at least as visible as the initializer >>> itself. So if you can see the `s` and `i`

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

> On Dec 21, 2015, at 10:39 PM, Brent Royal-Gordon > wrote: > >> Also, I don’t think it generates good API signatures. Take this example: >> >> struct S { >> let s: String >> let i: Int >> >> // user declares: >> memberwise init() {} >> //