Re: [swift-evolution] use standard syntax instead of "do" and "repeat"

> On Jan 3, 2016, at 1:37 PM, Dave Abrahams wrote: > >> >> On Jan 3, 2016, at 10:21 AM, Matthew Johnson wrote: >> >>> >>> On Jan 3, 2016, at 12:12 PM, Dave Abrahams via swift-evolution >>> wrote: >>> >>> On Jan

Re: [swift-evolution] [Proposal] Separate protocols and interfaces

> On Jan 3, 2016, at 8:52 PM, Drew Crawford via swift-evolution > wrote: > > I offer a +1, but I have two criticisms of the proposal. > > The first is that the example given in the proposal is stated a lot more > strongly than is true: > >> func compareTwo(first:

Re: [swift-evolution] use standard syntax instead of "do" and "repeat"

> On Jan 3, 2016, at 9:31 PM, Tyler Fleming Cloutier via swift-evolution > wrote: > > Please see inline comments. > > >> On Jan 3, 2016, at 6:48 PM, Tyler Fleming Cloutier via swift-evolution >> > wrote:

Re: [swift-evolution] [Proposal] Separate protocols and interfaces

> On Jan 3, 2016, at 9:08 PM, Drew Crawford wrote: > >> Existentials for protocols with Self and / or associated type requirements >> would require bindings for Self and / or the associated type(s). At least >> when you use a member that contains Self and / or an

Re: [swift-evolution] [Proposal] Separate protocols and interfaces

> On Jan 4, 2016, at 12:40 PM, Douglas Gregor wrote: > >> >> On Jan 4, 2016, at 10:30 AM, Matthew Johnson > > wrote: >> >>> >>> On Jan 4, 2016, at 12:21 PM, Douglas Gregor via swift-evolution >>>

Re: [swift-evolution] [Proposal] Separate protocols and interfaces

> On Jan 3, 2016, at 9:14 PM, Drew Crawford wrote: > > Sure, here's the start of the thread: > https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001856.html > >

Re: [swift-evolution] ternary operator ?: suggestion

tead of doing. My only excuse is that I'm "too > busy" > > > > >> On Mon, Jan 4, 2016 at 3:03 PM, Matthew Johnson via swift-evolution >> <swift-evolution@swift.org> wrote: >> >>> On Jan 4, 2016, at 2:37 PM, Paul Ossenbruggen vi

Re: [swift-evolution] ternary operator ?: suggestion

> On Jan 4, 2016, at 2:37 PM, Paul Ossenbruggen via swift-evolution > wrote: > > Good feedback, I am all for making it feel more like swift. Any ideas would > be welcome. I will also try to come up with some myself. My suggestion is to leave ternary alone and try

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] Separate protocols and interfaces

> On Jan 3, 2016, at 10:44 PM, Matthew Johnson wrote: > > >> On Jan 3, 2016, at 9:14 PM, Drew Crawford > > wrote: >> >> Sure, here's the start of the thread: >>

Re: [swift-evolution] [Proposal Draft] automatic protocol forwarding

> On Dec 29, 2015, at 5:44 PM, Dave Abrahams via swift-evolution > wrote: > > >> On Dec 29, 2015, at 12:06 PM, Kevin Ballard via swift-evolution >> > wrote: >> >> I briefly skimmed your proposal, so I

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

> On Dec 29, 2015, at 12:17 PM, Joe Groff via swift-evolution > wrote: > > We also have a problem with disambiguating same-named members that come from > different extensions, whether via protocol extensions or independent concrete > extensions from different

[swift-evolution] [Proposal Draft] automatic protocol forwarding

I have completed a first draft of a proposal to introduce automatic protocol forwarding. I’m looking forward to feedback from everyone! Automatic protocol forwarding Proposal: SE-

Re: [swift-evolution] [Pitch] Version-pinned patching of public declarations

Sorry if this should be clear already, but are you suggesting that @patch would allow patching of final or sealed types thus making them more palatable as defaults? This would surprise me, but if that is not what you are suggesting I don't follow how it relates to the final / sealed

Re: [swift-evolution] ternary operator ?: suggestion

> On Jan 5, 2016, at 10:51 AM, Sean Heber wrote: > >>> And maybe allow a special case for boolean where you can leave off the >>> “case true:” part: >>> >>> let x = something ? thing() else: otherThing() >>> >>> And then you could more or less replace ternary with this new

Re: [swift-evolution] ternary operator ?: suggestion

> On Jan 5, 2016, at 10:23 AM, Sean Heber wrote: > > >> On Jan 5, 2016, at 12:29 AM, Thorsten Seitz via swift-evolution >> wrote: >> >> I once suggested the following ternary like switch: >> >> let x = color ? >>case .Red: 0xFF >>

Re: [swift-evolution] ternary operator ?: suggestion

> On Jan 5, 2016, at 11:05 AM, Thorsten Seitz wrote: > >> >> Am 05.01.2016 um 17:29 schrieb Matthew Johnson : >> >> >>> On Jan 5, 2016, at 10:23 AM, Sean Heber wrote: >>> >>> On Jan 5, 2016, at 12:29 AM, Thorsten Seitz

Re: [swift-evolution] Support for newtype feature/typesafe calculations

> On Jan 5, 2016, at 11:16 AM, Thorsten Seitz via swift-evolution > wrote: > > >> Am 05.01.2016 um 17:11 schrieb Grzegorz Adam Hankiewicz via swift-evolution >> : >> >> The ideal would be for the compiler to pretend Euros or RefTablePk

Re: [swift-evolution] Support for newtype feature/typesafe calculations

Thanks for doing the work to collect links related to this topic! I am planning to give them a read. You may be interested in the proposal I am working on for automatic protocol forwarding. The first draft was posted to the list last week:

Re: [swift-evolution] ternary operator ?: suggestion

sions, so I could live with that restriction). You could still use the immediately invoked closure trick here. It’s not that bad. > The patterns would allow everything that is allowed for patterns in switch > statements. > > -Thorsten > > Am 05.01.2016 um 01:14 schrie

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] ternary operator ?: suggestion

an your version with 'match'. > > i.e. > let x = color match > case .Red: 0xFF > case .Red: 0x00FF00 > case .Red: 0xFF > default: 0xFF > > >>> On 2016-01-05, at 22:01:00, Matthew Johnson via swift-evolution >>> <

Re: [swift-evolution] Require use of override keyword to override dynamically dispatched methods defined in a protocol with a default implementation

> On Jan 6, 2016, at 3:48 AM, Greg Parker via swift-evolution > wrote: > >> >> On Jan 5, 2016, at 8:50 PM, Brent Royal-Gordon via swift-evolution >> wrote: >> >>> Taking inspiration from syntax used for methods in classes that override

Re: [swift-evolution] ternary operator ?: suggestion

> On Jan 5, 2016, at 12:37 PM, Marcelo Alves via swift-evolution > wrote: > > >> On Jan 5, 2016, at 16:06, Thorsten Seitz via swift-evolution >> > wrote: >> >> >>> Am 05.01.2016 um 18:12 schrieb Matthew

Re: [swift-evolution] ternary operator ?: suggestion

> On Jan 5, 2016, at 12:06 PM, Thorsten Seitz wrote: > > >> Am 05.01.2016 um 18:12 schrieb Matthew Johnson > >: >> >> On Jan 5, 2016, at 12:29 AM, Thorsten Seitz via swift-evolution >>

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] [Rejected] SE-0009 Require self for accessing instance members

> On Jan 6, 2016, at 11:47 AM, Douglas Gregor via swift-evolution > wrote: > > >> On Jan 6, 2016, at 6:56 AM, Greg Parker via swift-evolution >> wrote: >> >> >>> On Jan 6, 2016, at 6:17 AM, Honza Dvorsky via swift-evolution >>>

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] [Review] SE-0018 Flexible Memberwise Initialization

> On Jan 6, 2016, at 7:05 PM, David Owens II via swift-evolution > wrote: > > -1 for me. > >> On Jan 6, 2016, at 2:47 PM, Chris Lattner via swift-evolution >> > wrote: >> >> Hello Swift community, >> >>

Re: [swift-evolution] [Review] SE-0018 Flexible Memberwise Initialization

Sent from my iPad > On Jan 6, 2016, at 7:47 PM, Joe Groff <jgr...@apple.com> wrote: > > >>> On Jan 6, 2016, at 5:23 PM, Matthew Johnson via swift-evolution >>> <swift-evolution@swift.org> wrote: >>> >>> >>>> On Ja

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] [Review] SE-0018 Flexible Memberwise Initialization

> On Jan 6, 2016, at 6:04 PM, Dave Abrahams via swift-evolution > wrote: > > >> On Jan 6, 2016, at 2:47 PM, Chris Lattner via swift-evolution >> wrote: >> >> Hello Swift community, >> >> The review of "Flexible Memberwise

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] [Review] SE-0018 Flexible Memberwise Initialization

On Jan 6, 2016, at 7:21 PM, Matthew Johnson wrote: > On Jan 6, 2016, at 6:39 PM, Alex Johnson > wrote: > > Hi Matthew, > > Thanks for the explanation. > > Before getting into a deeper discussion, I'd like to

Re: [swift-evolution] [Review] SE-0018 Flexible Memberwise Initialization

> On Jan 6, 2016, at 6:39 PM, Félix Cloutier via swift-evolution > wrote: > > Meta: most reviews have the review dates in the Status field of their > document, this one doesn't. I was a little confused at first. > > For the proposal itself: > > # What is your

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] [Review] SE-0018 Flexible Memberwise Initialization

Sent from my iPad > On Jan 6, 2016, at 8:46 PM, Dave Abrahams <dabrah...@apple.com> wrote: > > > > Sent from my moss-covered three-handled family gradunza > >> On Jan 6, 2016, at 5:47 PM, Joe Groff <jgr...@apple.com> wrote: >> >> >>&g

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] automatic protocol forwarding

> On Dec 29, 2015, at 5:32 PM, Dave Abrahams <dabrah...@apple.com> wrote: > > >> On Dec 29, 2015, at 8:37 AM, Matthew Johnson via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> Motivation

Re: [swift-evolution] [Proposal Draft] automatic protocol forwarding

> On Dec 29, 2015, at 5:45 PM, Charles Srstka wrote: > > On Dec 29, 2015, at 5:38 PM, Matthew Johnson > wrote: >> >> >>> On Dec 29, 2015, at 5:25 PM, Charles Srstka >>

Re: [swift-evolution] [Proposal Draft] automatic protocol forwarding

> On Dec 29, 2015, at 6:10 PM, Brent Royal-Gordon > wrote: > >>> * Does it have to be a protocol? Why not also allow the concrete type of >>> the property you're forwarding to? Obviously you couldn't form a subtype >>> relationship (unless you could...), but this

Re: [swift-evolution] [Proposal Draft] automatic protocol forwarding

my iPad >> >> On Dec 31, 2015, at 10:09 AM, Dave Abrahams <dabrah...@apple.com >> <mailto:dabrah...@apple.com>> wrote: >> >>> >>> -Dave >>> >>>> On Dec 31, 2015, at 7:33 AM, Matthew Johnson via swift-evolution >>>&g

Re: [swift-evolution] [Proposal Draft] automatic protocol forwarding

> On Dec 31, 2015, at 5:04 AM, Tino Heth <2...@gmx.de> wrote: > > >> I don’t want this thread to get distracted with memberwise initialization > Makes sense in general, but Kotlin solves those problems as a whole, and the > major benefit of their approach is that everything fits together

Re: [swift-evolution] [Proposal Draft] automatic protocol forwarding

Sent from my iPad > On Dec 31, 2015, at 10:09 AM, Dave Abrahams <dabrah...@apple.com> wrote: > > > -Dave > >>> On Dec 31, 2015, at 7:33 AM, Matthew Johnson via swift-evolution >>> <swift-evolution@swift.org> wrote: >>> >>>

Re: [swift-evolution] [Proposal Draft] automatic protocol forwarding

Hi Kevin, Thanks for taking time to look at the proposal. The technique you show here is not bad, but it has several deficiencies IMO which are addressed by the solution in the proposal. 1. Forwarding should be an implementation detail, not exposed as it is with this method. 2. As such, the

Re: [swift-evolution] [Proposal Draft] automatic protocol forwarding

> On Dec 29, 2015, at 3:08 PM, Brent Royal-Gordon > wrote: > >> I have completed a first draft of a proposal to introduce automatic protocol >> forwarding. I’m looking forward to feedback from everyone! > > Some things I don't see discussed here: > > * Does it have

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] automatic protocol forwarding

> On Dec 30, 2015, at 11:33 AM, Patrick Gili > wrote: > > Just finished reading your write-up. It sounds similar to the Forwardable > module supported by the Ruby standard library > (http://ruby-doc.org/stdlib-2.0.0/libdoc/forwardable/rdoc/Forwardable.html). >

Re: [swift-evolution] use standard syntax instead of "do" and "repeat"

> On Jan 3, 2016, at 12:12 PM, Dave Abrahams via swift-evolution > wrote: > > >> On Jan 2, 2016, at 2:23 PM, Tyler Cloutier wrote: >> >> Please see comments inline. >> >>> On Dec 31, 2015, at 12:07 PM, Dave Abrahams via swift-evolution >>>

Re: [swift-evolution] [Proposal] Scoped resources (like C# using statement)

> On Dec 30, 2015, at 5:19 PM, Kevin Ballard via swift-evolution > wrote: > > On Wed, Dec 30, 2015, at 03:12 PM, Kevin Wooten via swift-evolution wrote: Another possibility I've thought of is defining `defer { val }` to guarantee that val remains

Re: [swift-evolution] [Proposal] Separate protocols and interfaces

> On Jan 4, 2016, at 11:43 AM, Douglas Gregor <dgre...@apple.com> wrote: > >> >> On Jan 4, 2016, at 6:24 AM, Matthew Johnson via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >>>

Re: [swift-evolution] [Proposal] Separate protocols and interfaces

, at 11:43 AM, Douglas Gregor <dgre...@apple.com >>> <mailto:dgre...@apple.com>> wrote: >>> >>>> >>>> On Jan 4, 2016, at 6:24 AM, Matthew Johnson via swift-evolution >>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.

Re: [swift-evolution] [Pitch] Use enums as enum underlying types

> On Dec 19, 2015, at 3:36 PM, Félix Cloutier wrote: > > I'm biased as the pitcher, but I find that an "inheritance" model would be > more straightforward than an inclusive model. > > If I understand you correctly, with this model: > >> enum NetworkException { >> case

Re: [swift-evolution] Proposal: Allow Type Annotations on Throws

Thanks for continuing the discussion David. > On Dec 21, 2015, at 1:30 PM, David Owens II wrote: > > I’m just going to interject a few thoughts in here. > >> On Dec 21, 2015, at 6:36 AM, Matthew Johnson > > wrote: >> >>

Re: [swift-evolution] Final by default for classes and methods

> On Dec 21, 2015, at 1:26 PM, Jordan Rose via swift-evolution > wrote: > > >> On Dec 20, 2015, at 3:40 , Tino Heth via swift-evolution >> > wrote: >> >> >>> Frankly, I think having `final` in the

Re: [swift-evolution] [Pitch] Replace 'inout' with '&'

> On Dec 21, 2015, at 12:25 PM, Joe Groff via swift-evolution > wrote: > > >> On Dec 19, 2015, at 4:10 PM, Erica Sadun > > wrote: >> >> What would the ramifications of the following be? Each addresses the >>

Re: [swift-evolution] [Proposal] Property behaviors

I really like the direction this is heading Joe! I agree it feels a lot nicer. It seems like the right long-term solution to me. Making behaviors an explicit construct in the language may lead to possibilities in the future that we cannot today which would not exist with the ad-hoc approach.

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 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 - Allow properties in Extensions

> On Dec 23, 2015, at 10:02 AM, Kevin Kachikian via swift-evolution > wrote: > > I don’t think hacking the runtime is much of an issue, more that it might > already be now. > > However part of the thinking behind the idea of extending extensions to > encompass

Re: [swift-evolution] Proposal - Allow properties in Extensions

I like this proposal in theory. The idea of localizing a member declaration inside the extension that actually uses that member certainly has advantages. At the same time, I have concerns about allowing this. In some ways it makes code less readable because it isn’t possible to see all of

Re: [swift-evolution] Final by default for classes and methods

> On Dec 22, 2015, at 1:31 PM, Kevin Ballard via swift-evolution > wrote: > > UIKit classes aren't subclassable because of a lack of sealed-by-default, > they're subclassable because until very recently there was no way to mark > classes as not being subclassable.

Re: [swift-evolution] Proposal: Allow Type Annotations on Throws

ing-swift-script/ >>> <http://alejandromp.com/blog/2015/12/23/rust-error-handling-swift-script/> >>> Will be interesting to try it again with the changes from this proposal ;) >>> >>> On 23 Dec 2015, at 05:58, Thorsten Seitz via swift-evolution >>

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

1:11 AM, Joe Groff <jgr...@apple.com >>> <mailto:jgr...@apple.com>> wrote: >>> >>>> >>>> On Dec 24, 2015, at 5:41 AM, Matthew Johnson via swift-evolution >>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> w

Re: [swift-evolution] Final by default for classes and methods

> On Dec 23, 2015, at 12:59 PM, Stephen Celis <stephen.ce...@gmail.com> wrote: > >> On Dec 23, 2015, at 1:55 PM, Matthew Johnson via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>> By "pay a price&q

Re: [swift-evolution] Final by default for classes and methods

> On Dec 23, 2015, at 12:26 PM, Michel Fortin <michel.for...@michelf.ca> wrote: > > Le 23 déc. 2015 à 10:07, Matthew Johnson via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> a écrit : >> >> 3) Annoyance. Some cons

Re: [swift-evolution] Proposal - Allow properties in Extensions

> On Dec 23, 2015, at 12:50 PM, John McCall via swift-evolution > wrote: > >> On Dec 23, 2015, at 7:05 AM, Paul Cantrell wrote: >> On Dec 22, 2015, at 10:45 PM, John McCall via swift-evolution >> wrote: >>> >>> when

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

> 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 - Allow properties in Extensions

. Matthew > On Dec 26, 2015, at 9:10 AM, Matthew Johnson via swift-evolution > <swift-evolution@swift.org> wrote: > >> >> On Dec 25, 2015, at 12:02 AM, John McCall <rjmcc...@apple.com >> <mailto:rjmcc...@apple.com>> wrote: >> >>> On Dec 24

Re: [swift-evolution] Proposal - Allow properties in Extensions

> On Dec 25, 2015, at 12:02 AM, John McCall wrote: > >> On Dec 24, 2015, at 12:10 PM, Matthew Johnson wrote: >>> On Dec 24, 2015, at 2:05 PM, John McCall wrote: >>> On Dec 24, 2015, at 11:48 AM, Matthew Johnson

Re: [swift-evolution] Proposal - Allow properties in Extensions

Sent from my iPad > On Dec 24, 2015, at 1:31 PM, John McCall wrote: > > >> On Dec 23, 2015, at 10:51 AM, Matthew Johnson wrote: >> >> On Dec 23, 2015, at 12:50 PM, John McCall via swift-evolution wrote:

Re: [swift-evolution] Proposal - Allow properties in Extensions

> On Dec 24, 2015, at 2:05 PM, John McCall wrote: > >> On Dec 24, 2015, at 11:48 AM, Matthew Johnson wrote: >>> On Dec 24, 2015, at 1:31 PM, John McCall wrote: >>> >>> On Dec 23, 2015, at 10:51 AM, Matthew Johnson

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

> On Dec 24, 2015, at 11:11 AM, Joe Groff <jgr...@apple.com> wrote: > >> >> On Dec 24, 2015, at 5:41 AM, Matthew Johnson via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> >> >&g

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

Sent from my iPhone On Dec 19, 2015, at 2:17 PM, Michael Henson via swift-evolution wrote: >> 1) Do you agree about using “associatedtype”? >> 2) If not, which keyword would you prefer to use? why? (you can introduce a >> new one) > > There is another

Re: [swift-evolution] Tuple accessor shorthand

Sorry, I didn’t read your post carefully enough. You are correct, this is not possible. If you need to dig 3 levels deep into a tuple you may have cases where structs would be more appropriate. > On Dec 18, 2015, at 10:01 AM, Alexandre Lopoukhine > wrote: > > Matthew,

Re: [swift-evolution] [Proposal Idea] dot shorthand for instance members

e $ instead of $0: > >someArray.map({ $.property }) > > And finally, combined with the single-statement shortcut: > >someArray.map($.property) > > l8r > Sean > > >> On Dec 18, 2015, at 9:31 AM, Matthew Johnson via swift-evolution >> <sw

Re: [swift-evolution] [Proposal Idea] catching functions for composable and cps error handling

I’m bumping this post in case you missed it Brent. I would find any comments you have on the differences between our approaches very interesting. Thanks! > On Dec 17, 2015, at 10:36 AM, Matthew Johnson via swift-evolution > <swift-evolution@swift.org> wrote: > > Brent,

[swift-evolution] Self behaves inconsistently in protocol method signatures

I have brought up the idea of a non-covarying Self a few times. I was surprised to realize that Self is actually non-covarying when used for parameters in protocol declarations! Here is an example demonstrating this: protocol P { func foo(s: Self) } protocol Q { func bar() -> Self }

Re: [swift-evolution] Self behaves inconsistently in protocol method signatures

t `ConformingSelf` return type. > > ~Robert Widmann > > 2015/12/28 11:49、Matthew Johnson via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> のメッセージ: > >> I have brought up the idea of a non-covarying Self a few times.

[swift-evolution] [Pitch] Option parameters (potential resilience advantages)

I've had an idea floating around in my mind for a couple weeks now and would like to find out what others think about it. The basic idea is really simple. It introduces an `@option` parameter attribute. Parameters with this attribute would behave like parameters with a default value at the

Re: [swift-evolution] Self behaves inconsistently in protocol method signatures

s inconsistent. >> The requirements on conforming types are different - invariance for Self >> parameters and covariance for Self return types. >> >> IMO it would be much more clear if this distinction was explicit rather than >> implicit based on the location

Re: [swift-evolution] Self behaves inconsistently in protocol method signatures

2:02 PM, Joe Groff <jgr...@apple.com >>> <mailto:jgr...@apple.com>> wrote: >>> >>>> >>>> On Dec 28, 2015, at 8:49 AM, Matthew Johnson via swift-evolution >>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>

Re: [swift-evolution] [Pitch] Option parameters (potential resilience advantages)

of them. Parameters with default values do cover that case but would also be less resilient than the “option” parameter idea. As I stated a couple of times now, I am not “proposing” this idea, simply sharing it to see what the community response is. > > Félix > >> Le 28 déc. 201

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

> On Dec 28, 2015, at 12:59 PM, Joe Groff <jgr...@apple.com> wrote: > >> >> On Dec 27, 2015, at 9:51 AM, Matthew Johnson via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >>> >>&g

Re: [swift-evolution] [Pitch] Option parameters (potential resilience advantages)

Sent from my iPhone > On Dec 28, 2015, at 2:04 PM, Joe Groff <jgr...@apple.com> wrote: > > >>> On Dec 28, 2015, at 11:46 AM, Matthew Johnson via swift-evolution >>> <swift-evolution@swift.org> wrote: >>> >>> >>> On Dec 2

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] Property behaviors

I have been thinking further about the compiler diagnostics for `delayed`. It might be interesting to consider making various compiler diagnostics available to any behavior rather than having a special case in the compiler for `delayed`. Here are some examples: * By default properties with

Re: [swift-evolution] Final by default for classes and methods

Sent from my iPad > On Dec 22, 2015, at 3:43 AM, Tino Heth <2...@gmx.de> wrote: > > >> I can see why you view it this way, but access control and inheritability >> are orthogonal. > as I understand orthogonal (mathematical background), it is definitely not > the case: > I can't inherit what

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

PM, Chris Lattner <clatt...@apple.com> wrote: > > On Dec 21, 2015, at 11:32 AM, Matthew Johnson via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> I have completed a draft of the proposal I have been working on for fle

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

> > My concern is that this starts to be more complicated and magical. I’d > actually cut this from the proposal. > > The last change I would make is that if any property has an assignment in the > declaration, it cannot be memberwise initialized. > > struct S { > let s:

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 <tseit...@icloud.com> wrote: > > >> Am 22.12.2015 um 05:43 schrieb Matthew Johnson via swift-evolution >> <swift-evolution@swift.org>: >> >> What do you think the downsides are of synthesizing

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

> On Dec 22, 2015, at 11:30 AM, Erica Sadun via swift-evolution > wrote: > > As SE-0011 states, the concept of typealias is overloaded. > In one case, it's really just typedef. > In the other it's a stand-in for a deferred type that is specified by > conforming

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

M members x N initializers)? If you haven’t taken a look at the updated proposal please do so. I’m sure there will still be things you are not totally comfortable with but you might like it better than yesterday's draft. > > -David > >> On Dec 22, 2015, at 8:46 AM, Matthew

Re: [swift-evolution] Proposal: Allow Type Annotations on Throws

> On Dec 21, 2015, at 3:00 PM, David Owens II wrote: > > >> I understand that Rust is not doing implicit conversions, but the effect for >> the user is pretty much the same. The try macro is converting the >> underlying error to the type that can be propagated. As I

Re: [swift-evolution] Final by default for classes and methods

Sent from my iPhone > On Dec 23, 2015, at 2:28 PM, Felipe Cypriano via swift-evolution > wrote: > >> On Wed, Dec 23, 2015, at 11:12, Felipe Cypriano wrote: >> About sealed vs final. I think this is a do or do not, sealed would just >> complicate things by having

Re: [swift-evolution] Final by default for classes and methods

> On Dec 23, 2015, at 8:43 PM, Charles Srstka <cocoa...@charlessoft.com> wrote: > >> On Dec 23, 2015, at 8:15 PM, Matthew Johnson via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> I’m not trying

  1   2   3   4   5   6   7   8   9   10   >