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 {} pub

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

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 Jan 6, 2016, at 3:39 PM, Matthew Johnson > wrote:

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, at 5:08 PM, Joe Groff wrote: I find it surprising that y

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 initialization of 'var's based on >>> whether their setter is v

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 the same as >> setting, and memberwise init

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 Scala’s syntax > but it is

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 > access to the memb

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

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 access to the member anyway; this is why `let` properties can be initialized,

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). cla

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 no

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

Ok, that makes sense. -Thorsten > Am 03.01.2016 um 00:24 schrieb Chris Lattner : > > >> On Jan 2, 2016, at 2:48 PM, Thorsten Seitz wrote: >> >> One question just occurred to me: do we really need the keyword „memberwise“ >> anymore? Wouldn’t just using "init(…)“ be sufficient? > > It woul

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 as

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

An alternative would be to take a leaf out of Scala's book and use brackets following the type name. e.g: struct Rect(var origin: Point = Point(), var size: Size = Size()) { init(center: Point, size: Size) { let originX = center.x - (size.width / 2) let originY = c

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, or its equivalent. The >

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 a

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 the type. There are good

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 defaultOriginRe

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 will

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

> On Jan 2, 2016, at 2:48 PM, Thorsten Seitz wrote: > > One question just occurred to me: do we really need the keyword „memberwise“ > anymore? Wouldn’t just using "init(…)“ be sufficient? It wouldn’t be necessary to make the parser work, but I think we’d want something to make it clear what

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

One question just occurred to me: do we really need the keyword „memberwise“ anymore? Wouldn’t just using "init(…)“ be sufficient? -Thorsten ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolut

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 don’

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 >> mailto:swift-evolution@swift.org>> wrote: >> >>> >>> On Dec 26, 2015, at 11:31 PM, Chris Lattner >> > wrote: >>> >>> On Dec 25, 2015, at 12

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 > > wrote: > Discussion on a couple of t

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

> On Dec 26, 2015, at 11:31 PM, Chris Lattner wrote: > > On Dec 25, 2015, at 12:04 PM, Matthew Johnson > wrote: Discussion on a couple of topics continues inline below as well. >>> >>> Great, comments below: >> >> Thanks for continuing the discussion. I ha

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

On Dec 25, 2015, at 12:04 PM, Matthew Johnson wrote: >>> Discussion on a couple of topics continues inline below as well. >> >> Great, comments below: > > Thanks for continuing the discussion. I have updated the proposal to reflect > the core functionality and moved everything else to the futu

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 solving

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 to >>> respond to both of your responses, I hop

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

> 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 to >> respond to both of your responses, I hope this comes across somewhat >> coherent: > > Excellent, thanks! I have completed a third draft

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 >> > wrote: >>> On Dec 24, 2015, at 5:41 AM, Matthew Johnson

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

> On Dec 24, 2015, at 12:17 PM, Matthew Johnson wrote: > >> >> On Dec 24, 2015, at 11:11 AM, Joe Groff > > wrote: >> >>> >>> On Dec 24, 2015, at 5:41 AM, Matthew Johnson via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >>> >>> >>> Sent from my

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 >> mailto:swift-evolution@swift.org>> wrote: >> >> >> >> Sent from my iPad >> >>> On Dec 24, 2015, at 5:46 AM, Thorsten Seitz >> > wrote: >>

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

> 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 Seitz wrote: >> >> >>> Am 22.12.2015 um 18:30 schrieb Matthew Johnson : >>> >>> My proposal is specifically suggesting that we treat “initial v

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 initialization that always happens. IMO the current >> b

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

> 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 initialization that always happens. IMO the current > behavior is limiting and problematic in a number of ways. > > If we make the change I

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 >> this proposal from a slightly different angle

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

> On Dec 22, 2015, at 1:36 PM, Guillaume Lessard > wrote: > > (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

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 still been consistent

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 differe

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

> On Dec 22, 2015, at 11:38 AM, Félix Cloutier wrote: > > > Sorry to sidetrack the discussion, but does that mean that using `let` > properties in a type where memory layout is important is possibly not > forward-compatible? Swift has no support for such a type, when it does, it should be opt

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

> Problem 2: This can cause very surprising performance issues, because it > forces the let property to be stored. With the previous example, it is a > goal for us to be able to compile: > > public class X { > let a = 42 > } > > into the equivalent of: > > public class X { > var a : Int {

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 A { public let propert

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 to really like the approa

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

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. I think this places me on Guillaume's side here. Félix > Le 22 déc. 2015 à 14:20:47, Guillaume Lessard via swift-evolution > a écrit : > > >> On 22 déc. 20

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 definition. > Why woul

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 that

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 that’s not what you want, don’t

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

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 that’s not what you want, don’t initialize it here. } Cheers, Guillaume Lessard ___

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 semantic versioning. > > This would be awesom

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

> 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 semantic versioning. This would be awesome to have, especially integrated in. The way we handle this internally is less than ideal, so have

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 may have been a bad example as you handle

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 the `s` and `i` parameters,

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

> 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 may have been a bad example as you handle the case where they wouldn’t be a breaking change by promoting the

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 ships: > > struct Per

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 “initial value”? > > When using the memberwise

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

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 ships: struct Person { let name: String let age: Int } When you use the implicit memberwise ini

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 assigned a value twice. Firs

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 initi

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 >>> let i: Int >>> >>> // user declares:

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 David. I’m glad tha

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 >> >> // user declares: >>

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` parameters, you can also see th

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

>> 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` parameters, you can also see the >> `s` and `i` properties. It's not going to expose anything that

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() {} >> // compiler synthesizes: >>

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

> 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() {} > // compiler synthesizes: > init(s: String, i: Int) { > self.s = s >

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

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. Also, I don’t think it generates good API signatures. Take this example: struct S {

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

> On Dec 21, 2015, at 7:47 PM, Chris Lattner wrote: > > On Dec 21, 2015, at 11:32 AM, Matthew Johnson via swift-evolution > mailto:swift-evolution@swift.org>> wrote: >> I have completed a draft of the proposal I have been working on for flexible >> memberwise initialization. I am really looki

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 isn’t clear to me >> whet

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

> On Dec 21, 2015, at 8:03 PM, Dave Abrahams wrote: > >> >> On Dec 21, 2015, at 5:47 PM, Chris Lattner via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> On Dec 21, 2015, at 11:32 AM, Matthew Johnson via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >>> I h

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

> 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 isn’t clear to me whether the > memberwise initializers should come before explicit arguments

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 > mailto:swift-evolution@swift.org>> wrote: >> I have completed a draft of the proposal I have been working on for flexible >> memberwise initializat

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

On Dec 21, 2015, at 11:32 AM, Matthew Johnson via swift-evolution wrote: > I have completed a draft of the proposal I have been working on for flexible > memberwise initialization. I am really looking forward to your input and > will be refining the proposal based on our discussion. > > I am

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

Sent from my iPhone > On Dec 21, 2015, at 2:21 PM, Tino Heth <2...@gmx.de> wrote: > > I already encountered a downside of the memberwise initializer - but that's > already addressed (at least partly) as point 4) in Chris' list: > Let's say I have a struct with 10 members, and all of them have

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

I already encountered a downside of the memberwise initializer - but that's already addressed (at least partly) as point 4) in Chris' list: Let's say I have a struct with 10 members, and all of them have a default; the current initializer doesn't use the defaults, so you have the burden of fillin

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

I have completed a draft of the proposal I have been working on for flexible memberwise initialization. I am really looking forward to your input and will be refining the proposal based on our discussion. I am including a current snapshot of the proposal in this message. I will keep the propo