Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0089: Renaming String.init(_: T)

I don't recall whether it was in this thread or another that this point was made by the core team, but if I'm remembering correctly: it was shared that the protocol is now called CustomStringConvertible because conforming types provide a *custom* description, not merely an ordinary description.

Re: [swift-evolution] [Pitch] Make `return` optional in computed properties for a single case

+ 1 from me as well for the already stated reasons. - Dennis > On May 28, 2016, at 2:15 AM, Matthew Johnson via swift-evolution > wrote: > > > > Sent from my iPad > > On May 27, 2016, at 6:15 PM, Brent Royal-Gordon via swift-evolution >

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0089: Renaming String.init(_: T)

Some feedback: I wonder if ValuePreservingStringConvertible having an initializer restricts its use case at all? Plus, ValuePreservingStringConvertible seems very similar to RawRepresentable with a RawValue of String. Lossless sounds nice to me. Or ‘canonical’ I had wondered, but lossless

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0089: Renaming String.init(_: T)

> https://github.com/austinzheng/swift-evolution/blob/az-edit-89/proposals/0089-rename-string-reflection-init.md I prefer the more conservative and backwards-compatible option of using `description` and conforming `ValuePreservingStringConvertible` to `CustomStringConvertible`. This is for

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0089: Renaming String.init(_: T)

I'd hope not. You can't guarantee String -> Double -> String roundtripping, but Double -> String -> Double should be lossless. On Sat, May 28, 2016 at 00:11 Jacob Bandes-Storch wrote: > Does "lossless" preclude floating-point numbers from being printed in > decimal unless

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0089: Renaming String.init(_: T)

Does "lossless" preclude floating-point numbers from being printed in decimal unless they are exactly representable? On Fri, May 27, 2016 at 9:04 PM Austin Zheng via swift-evolution < swift-evolution@swift.org> wrote: > Thanks, I like "Lossless" too. Further suggestions on naming would be >

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0089: Renaming String.init(_: T)

Thanks, I like "Lossless" too. Further suggestions on naming would be appreciated from anyone. Austin > On May 27, 2016, at 9:03 PM, Xiaodi Wu wrote: > > This looks good. I like your use of the term "lossless"; perhaps we can use > it consistently, i.e.

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0089: Renaming String.init(_: T)

This looks good. I like your use of the term "lossless"; perhaps we can use it consistently, i.e. LosslessStringConvertible. The implication by comparison would be that CustomStringConvertible makes no guarantee of losslessness. On Fri, May 27, 2016 at 23:52 Austin Zheng via swift-evolution <

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0089: Renaming String.init(_: T)

Hello swift-evolution, I've put together a preliminary v2 of the proposal, taking into account feedback expressed on this thread. I would appreciate any comments, suggestions, or criticisms.

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

A different way of layering could be allowing value types to be composed, where the outer type inherits the inner member’s properties and methods. Let’s say you want only fields ‘contentID’ and ‘contentData' to participate in equality and hashing, but not ‘revisionID': struct ContentInfo :

Re: [swift-evolution] [Review] SE-0099: Restructuring Condition Clauses

I was using the word that the proposal author even used! Couldn't the same be said for the comma though? Sent from my iPad > On May 27, 2016, at 10:48 PM, Jacob Bandes-Storch wrote: > > I haven't had time to carefully read this whole thread, but I don't think I > agree

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0089: Renaming String.init(_: T)

Is there any possibility we can break from this? Especially as: 1. ValuePreservingStringConvertible expects its description to be value preserving, but current Cocoa implementations are not. 2. ‘Description’ doesn’t really convey the meaning of ‘value preserving’ in my mind, but is a valuable

Re: [swift-evolution] [Review] SE-0099: Restructuring Condition Clauses

I haven't had time to carefully read this whole thread, but I don't think I agree that this syntax is "uglier". Isn't it true that semicolons are used regularly in English; that they delimit separate clauses, boolean or otherwise; and that the proposed syntax mirrors English grammar pretty well

Re: [swift-evolution] [Pitch] Circling back to `with`

Just some alternate naming suggestions for with() and withVar(), as the naming guidelines suggest -ed/-ing: withVar altered() // Changes a value copy / reference and returns it mutated() // Or this, but uses value-specific term ‘mutate’ with inspect() // Works with an immutable copy, has

Re: [swift-evolution] [Review] SE-0099: Restructuring Condition Clauses

As a *user* of the language, I find it a little disconcerting that we would make the syntax uglier just to serve the grammar. Where is the benefit to the user with this? Especially at the cost of making it slightly uglier? And sorry, but what is a boolean assertion? :embarrassed face: Brandon

Re: [swift-evolution] [Review] SE-0099: Restructuring Condition Clauses

> On May 27, 2016, at 7:50 PM, Xiaodi Wu wrote: > > I don't believe that was the case with the semicolons in the original for;; > loop, was it? No, I don’t believe so, but that’s gone now. And it is pretty uncommon to see `for` loop clauses on multiple lines. Not so

Re: [swift-evolution] [Review] SE-0099: Restructuring Condition Clauses

I don't believe that was the case with the semicolons in the original for;; loop, was it? On Fri, May 27, 2016 at 20:37 Matthew Johnson via swift-evolution < swift-evolution@swift.org> wrote: > > > Sent from my iPad > > On May 27, 2016, at 7:22 PM, Erica Sadun wrote: > > >

Re: [swift-evolution] [Review] SE-0099: Restructuring Condition Clauses

Sent from my iPad > On May 27, 2016, at 7:22 PM, Erica Sadun wrote: > > >> On May 27, 2016, at 6:19 PM, Matthew Johnson wrote: Also, can someone refer me to an example of this statement: "This proposal resolves this problem by

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

> On May 27, 2016, at 6:26 PM, Brent Royal-Gordon > wrote: > >> guard >> x == 0 && a == b && c == d && >> let y = optional, w = optional2, v = optional 3 && >> z == 2 >> else { ... } >> >> Figuring out where to break the first line into expression and into >>

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

> guard > x == 0 && a == b && c == d && > let y = optional, w = optional2, v = optional 3 && > z == 2 > else { ... } > > Figuring out where to break the first line into expression and into condition > (after the `d`) could be very challenging to the compiler. I'm not sure it is. `let` and

Re: [swift-evolution] [Review] SE-0099: Restructuring Condition Clauses

> On May 27, 2016, at 6:19 PM, Matthew Johnson wrote: >>> Also, can someone refer me to an example of this statement: "This proposal >>> resolves this problem by retaining commas as separators within clauses (as >>> used elsewhere in Swift) and introducing semicolons to

Re: [swift-evolution] [Review] SE-0099: Restructuring Condition Clauses

Sent from my iPad > On May 27, 2016, at 7:13 PM, Erica Sadun via swift-evolution > wrote: > > >> On May 27, 2016, at 3:06 PM, Brandon Knope via swift-evolution >> wrote: >> >> Second, I have really gotten use to not needing to use

Re: [swift-evolution] [Pitch] Make `return` optional in computed properties for a single case

Sent from my iPad On May 27, 2016, at 6:15 PM, Brent Royal-Gordon via swift-evolution wrote: >> The idea is simple: >> >>• Can we make return keyword optional in cases like this? >>• Shouldn’t this behave like @autoclosure or @noescape? > > This actually

Re: [swift-evolution] [Review] SE-0099: Restructuring Condition Clauses

> On May 27, 2016, at 3:06 PM, Brandon Knope via swift-evolution > wrote: > > Second, I have really gotten use to not needing to use semicolons, and this > proposal seems to use/require them in very common situations. > > After shedding the requirement of

Re: [swift-evolution] [Pitch] Make `return` optional in computed properties for a single case

+1. Completely agree with Brent's views here. On 28 May 2016, at 9:15 AM, Brent Royal-Gordon via swift-evolution wrote: >> The idea is simple: >> >>• Can we make return keyword optional in cases like this? >>• Shouldn’t this behave like @autoclosure or

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

> > https://github.com/apple/swift-evolution/blob/master/proposals/0099-conditionclauses.md > • What is your evaluation of the proposal? Oof. I am not a fan of this syntax. `;` reads very strongly as a statement ender to me, and yet at the same time, it's still visually

Re: [swift-evolution] [Pitch] Property reflection

> On May 27, 2016, at 9:57 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> I'm not sure how this alternative is related to access control. Austin's >> proposal could enforce access control in the same way and he mentioned he >> was inclined to enforce it

Re: [swift-evolution] [Pitch] Make `return` optional in computed properties for a single case

> The idea is simple: > > • Can we make return keyword optional in cases like this? > • Shouldn’t this behave like @autoclosure or @noescape? This actually doesn't have anything to do with @autoclosure or @noescape. Any one-expression closure can omit the `return` statement and have

Re: [swift-evolution] [Pitch] Circling back to `with`

> On May 27, 2016, at 5:12 PM, Brent Royal-Gordon via swift-evolution > wrote: > >>> Just mentioning it as to end up... with the proper name for this new >>> function. >> >> Naming can always be bikeshedded. > > One possibility is to split `with` in two: I much

Re: [swift-evolution] [Pitch] Circling back to `with`

Hi, I really like the proposal as it's in the last draft. And the examples are really good, specially the one that is similar to the Ruby tap. I've been using the Then extension for a while and makes the initialization much nicer. I also use a set of extensions that allow me to print

Re: [swift-evolution] [Pitch] Property reflection

> On May 27, 2016, at 5:37 PM, Anders Ha wrote: > >> >> On 28 May 2016, at 6:00 AM, Brent Royal-Gordon via swift-evolution >> wrote: >> I'm not sure how much metadata is necessary beyond name (in the key) and type (discussed soon).

Re: [swift-evolution] [Pitch] Property reflection

> On 28 May 2016, at 6:00 AM, Brent Royal-Gordon via swift-evolution > wrote: > >>> I'm not sure how much metadata is necessary beyond name (in the key) and >>> type (discussed soon). >> >> In the future we may have user-defined attributes. It could be very useful

Re: [swift-evolution] [Pitch] Circling back to `with`

>> Just mentioning it as to end up... with the proper name for this new >> function. > > Naming can always be bikeshedded. One possibility is to split `with` in two: - A plain `with` whose closure parameter is not mutable and which is marked `@discardableResult`. - A `withVar` whose

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

> On May 27, 2016, at 5:07 PM, plx via swift-evolution > wrote: > > >> On May 27, 2016, at 3:22 PM, Ricardo Parada via swift-evolution >> > wrote: >> >> Inline >> >> >> On May 27, 2016, at 2:52

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

> On May 27, 2016, at 3:22 PM, Ricardo Parada via swift-evolution > wrote: > > Inline > > > On May 27, 2016, at 2:52 PM, Matthew Johnson > wrote: > >> >>> On May 27, 2016, at 12:48 PM, Ricardo

Re: [swift-evolution] [Pitch] Property reflection

>> I'm not sure how much metadata is necessary beyond name (in the key) and >> type (discussed soon). > > In the future we may have user-defined attributes. It could be very useful > to expose that. This is true. Actually, I'm wondering if property behaviors should be able to essentially

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0089: Renaming String.init(_: T)

on Thu May 26 2016, Patrick Smith wrote: >> On 27 May 2016, at 2:40 PM, Austin Zheng via swift-evolution >> wrote: >> >> Any of the NSObject subclass candidates may require their >> `description`s to be altered to meet the semantics,

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0089: Renaming String.init(_: T)

on Thu May 26 2016, Austin Zheng wrote: > I think this is an incredible idea. > > Should we eventually prepare an updated proposal? I think that's what “returned for revision” implies ;-) > Given the need for further discussion I'd be happy to drive it > forward,

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

> On May 27, 2016, at 3:22 PM, Ricardo Parada wrote: > > Inline > > > On May 27, 2016, at 2:52 PM, Matthew Johnson > wrote: > >> >>> On May 27, 2016, at 12:48 PM, Ricardo Parada >>

Re: [swift-evolution] [Pre-proposal] Replace [Foo] With CollectionType

Sent from my iPad > On May 27, 2016, at 3:43 PM, Dave Abrahams via swift-evolution > wrote: > > > On May 24, 2016, at 9:35 PM > > on Tue May 24 2016, Matthew Johnson wrote: > >> , Austin Zheng >> wrote: >> >>

Re: [swift-evolution] [Review] SE-0099: Restructuring Condition Clauses

I am giving a -1 for this proposal. While I am sure it has merit, I am finding it to be a really technical change (meaning it makes the language look more technical at the expense of some of its beauty) First, I do not find this example very compelling: guard x == 0, let y = optional

Re: [swift-evolution] [Pre-proposal] Replace [Foo] With CollectionType

On May 24, 2016, at 9:35 PM on Tue May 24 2016, Matthew Johnson wrote: > , Austin Zheng > wrote: > > On Tue, May 24, 2016 at 4:24 PM, Brent Royal-Gordon > wrote: > > > I’m not sure what you mean about

Re: [swift-evolution] [Pre-proposal] Replace [Foo] With CollectionType

> On May 27, 2016, at 1:53 PM, Xiaodi Wu wrote: > > Firstly, the syntax is about to get a lot cleaner. Soon, your example will be: > > func doSomething< > S: Sequence, T: Sequence, U: Sequence > >(foos: S, bars: T, bazzes: U) > where S.Element == Foo, T.Element == Bar,

Re: [swift-evolution] [Pitch] Property reflection

Would it let me get a property if it does not correspond to a property, or computed property? For example, would I be able to get the value returned by a fullName() instance method that concatenates the firstName and lastName properties together and returns the result? Or would it only work

Re: [swift-evolution] [Pre-proposal] Replace [Foo] With CollectionType

on Fri May 27 2016, Xiaodi Wu wrote: > Firstly, the syntax is about to get a lot cleaner. Soon, your example will be: > > func doSomething< > S: Sequence, T: Sequence, U: Sequence >>(foos: S, bars: T, bazzes: U) > where S.Element == Foo, T.Element == Bar, U.Element ==

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

Inline > On May 27, 2016, at 2:52 PM, Matthew Johnson wrote: > > >> On May 27, 2016, at 12:48 PM, Ricardo Parada wrote: >> >> >> What if we get the error when trying to use it? For example, if a struct >> uses a value that is not Equatable /

Re: [swift-evolution] [Pitch] Property reflection

> On May 27, 2016, at 2:57 PM, Brent Royal-Gordon > wrote: > >> I'm not sure how this alternative is related to access control. Austin's >> proposal could enforce access control in the same way and he mentioned he >> was inclined to enforce it the same way you are

Re: [swift-evolution] [Pitch] Property reflection

> I'm not sure how this alternative is related to access control. Austin's > proposal could enforce access control in the same way and he mentioned he was > inclined to enforce it the same way you are describing. > > The reason I say it is tricky is because enforcing access control in this way

Re: [swift-evolution] [Review] SE-0099: Restructuring Condition Clauses

> On May 27, 2016, at 9:11 PM, Joe Groff via swift-evolution > wrote: > > Hello Swift community, > > The review of SE-0099 “Restructuring Condition Clauses” begins now and runs > through June 3, 2016. The proposal is available here: > > >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

On May 27, 2016, at 1:47 PM, Matthew Johnson wrote: > >> >> On May 27, 2016, at 2:37 PM, Erica Sadun > > wrote: >> Given the whole newline groundswell that has emerged on SE, I did consider >> it but when I mocked up

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

> On May 27, 2016, at 2:37 PM, Erica Sadun wrote: > > >> On May 27, 2016, at 1:28 PM, Matthew Johnson via swift-evolution >> wrote: >> >>> • What is your evaluation of the proposal? >> >> +1. I believe it improves the clarity of

Re: [swift-evolution] [Pitch] Circling back to `with`

On May 25, 2016, at 5:34 PM, Dany St-Amant wrote: > Le 25 mai 2016 à 14:28, Erica Sadun via swift-evolution > > a écrit : > >> Over the past couple of days, the Twitters have discovered some work I'd >> done on

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

> On May 27, 2016, at 10:48 AM, Matthew Johnson wrote: > >> >> On May 27, 2016, at 10:37 AM, plx via swift-evolution >> > wrote: >> >> >>> On May 26, 2016, at 1:00 PM, T.J. Usiyan via swift-evolution >>>

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

> On May 27, 2016, at 2:26 PM, Austin Zheng wrote: > > Thanks for all your thoughtful replies. > > I'm not really invested in arguing this much further, as it's mainly a > stylistic thing that I could live with and also probably a hopeless battle > (given how everyone

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

> On May 27, 2016, at 1:28 PM, Matthew Johnson via swift-evolution > wrote: > >> • What is your evaluation of the proposal? > > +1. I believe it improves the clarity of condition clauses and as the > proposal suggests, I think it will make it easier for

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

> • What is your evaluation of the proposal? +1. I believe it improves the clarity of condition clauses and as the proposal suggests, I think it will make it easier for programmers to learn and understand what is possible with them. Did you consider allowing the semicolon to be omitted

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

Thanks for all your thoughtful replies. I'm not really invested in arguing this much further, as it's mainly a stylistic thing that I could live with and also probably a hopeless battle (given how everyone else disagrees). But I would like to address a few final points. (inline) On Fri, May 27,

[swift-evolution] Allow partial applications of mutating methods in @noescape contexts

struct MyStruct { var count = 0 mutating func add(amount: Int) { count += amount } } var myStruct = MyStruct() [1, 2, 3, 4].forEach(myStruct.add) This code currently doesn’t compile because myStruct.add is a partial application of a mutating method, which is forbidden.

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

> On May 27, 2016, at 1:36 PM, Austin Zheng wrote: > > (inline) > > On Fri, May 27, 2016 at 10:09 AM, Thorsten Seitz > wrote: > >> Am 27.05.2016 um 18:36 schrieb Austin Zheng >

[swift-evolution] [Review] SE-0099: Restructuring Condition Clauses

Hello Swift community, The review of SE-0099 “Restructuring Condition Clauses” begins now and runs through June 3, 2016. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0099-conditionclauses.md Reviews are an important part of the Swift

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

> On May 27, 2016, at 11:36 AM, Austin Zheng wrote: > > I think the parentheses are the fundamental aspect of the suggestion :). Yes I know. I guess we disagree on this point. It seems like a matter of style to me, not something to require. > > Let me turn the

Re: [swift-evolution] Proposal SE-0009 Reconsideration

As another colorblind developer, I have trouble paying attention to the syntax highlighting. I didn’t even notice that member variables were colored until someone mentioned it on this list. > On May 23, 2016, at 9:43 AM, Jeff Kelley via swift-evolution > wrote: >

Re: [swift-evolution] [Pitch] Property reflection

Yes, it was pretty much meant as a KVC-like feature for Swift. Get a reference to a property from a string which would allow you to get and set its value. On Fri, May 27, 2016 at 11:53 AM, Ricardo Parada wrote: > > On May 26, 2016, at 9:25 PM, Austin Zheng via swift-evolution <

Re: [swift-evolution] [Pre-proposal] Replace [Foo] With CollectionType

Firstly, the syntax is about to get a lot cleaner. Soon, your example will be: func doSomething< S: Sequence, T: Sequence, U: Sequence >(foos: S, bars: T, bazzes: U) where S.Element == Foo, T.Element == Bar, U.Element == Baz Second, this syntax shows necessary complexity. Case in point: an array

Re: [swift-evolution] [Pitch] Property reflection

> On May 26, 2016, at 9:25 PM, Austin Zheng via swift-evolution > wrote: > > ``` > myPerson.typedReadWriteProperty("age")?.set(30) > > try myPerson.allNamedProperties["age"]?.set(30) > ``` > Can you elaborate on what this API would be used for? KVC? For instance,

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

> On May 27, 2016, at 12:48 PM, Ricardo Parada wrote: > > > What if we get the error when trying to use it? For example, if a struct > uses a value that is not Equatable / Hashable then it would not be Equatable > / Hashable and you would not find out until you tried to use

Re: [swift-evolution] [Pre-proposal] Replace [Foo] With CollectionType

> On May 27, 2016, at 12:05 PM, Charles Srstka via swift-evolution > wrote: > >> On May 27, 2016, at 9:31 AM, plx via swift-evolution >> > wrote: >> >> For the Sequence/Collection it’s a lot of work for

Re: [swift-evolution] [Pitch] Property reflection

> On May 27, 2016, at 11:54 AM, Austin Zheng via swift-evolution > wrote: > > I think there is a consensus forming that we probably don't yet know enough > about Swift's future capabilities to nail down specific designs yet. (Not > that I want to stop people from

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

(inline) On Fri, May 27, 2016 at 10:09 AM, Thorsten Seitz wrote: > > Am 27.05.2016 um 18:36 schrieb Austin Zheng : > > I think the parentheses are the fundamental aspect of the suggestion :). > > Let me turn the question around. If tuples were

[swift-evolution] [Pitch] Make `return` optional in computed properties for a single case

The idea is simple: Can we make return keyword optional in cases like this? Shouldn’t this behave like @autoclosure or @noescape? type A { var characters: [Character] = … var string: String { String(self.characters) } var count: Int { 42 } } Is this worth a proposal or Swifty enough,

[swift-evolution] Foundational Algorithms prototype

FYI: notwithstanding the recent deferral of rotate from the standard library, I believe such foundational algorithms are very important for Swift. I have established https://github.com/apple/swift/blob/master/test/Prototypes/Algorithms.swift with implementations of rotate and stablePartition.

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

What if we get the error when trying to use it? For example, if a struct uses a value that is not Equatable / Hashable then it would not be Equatable / Hashable and you would not find out until you tried to use it. Would that be bad? > On May 26, 2016, at 11:35 AM, Matthew Johnson via

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

For me requiring parentheses for this 'feature' will confuse in most cases as looks similar to tuple definition: let x : (Int, String, Bool) = oneThing let y : (MyProto & Hashable) = anotherThing but below looks IMO more clean and I instantly(don't need to parse first open parenthesis) see

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

> On May 25, 2016, at 7:07 AM, Thorsten Seitz via swift-evolution > wrote: > This is unfortunate, because then the meaning of "existential" and > "non-existential" in Swift are just the opposite of their respective meaning > in standard terminology :-( I don't know

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

> Am 27.05.2016 um 18:36 schrieb Austin Zheng : > > I think the parentheses are the fundamental aspect of the suggestion :). > > Let me turn the question around. If tuples were declared like this: > > let myTuple : Int, String, Bool = (10, "hello", false) > > would the

Re: [swift-evolution] [Pre-proposal] Replace [Foo] With CollectionType

> On May 27, 2016, at 9:31 AM, plx via swift-evolution > wrote: > > For the Sequence/Collection it’s a lot of work for IMHO a rather minor > convenience, but for more-complex type associated-type relationships it could > start to pay its own way. Is it really that

Re: [swift-evolution] Enhanced existential types proposal discussion

> Am 27.05.2016 um 17:33 schrieb Matthew Johnson : > >> >> On May 27, 2016, at 3:45 AM, Austin Zheng via swift-evolution >> > wrote: >> >> As far as I understand it (and the core team as well, judging from

Re: [swift-evolution] [Pitch] Property reflection

I think there is a consensus forming that we probably don't yet know enough about Swift's future capabilities to nail down specific designs yet. (Not that I want to stop people from talking about them if they wish.) However, now that there is a conversation topic about reflection, I also wanted

Re: [swift-evolution] [Idea] Switch Statement with Optional Binding

Nice! However, the case statements may increase as shown below and I was wondering if it will still be worth it(Greetings core team!) in adding some syntactic sugar as aforementioned... switch cityIDs["Paris"] { case let .Some(parisCityID) where 0..<3 ~= parisCityID: print("Paris city ID:

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

I think the parentheses are the fundamental aspect of the suggestion :). Let me turn the question around. If tuples were declared like this: let myTuple : Int, String, Bool = (10, "hello", false) would the type be more or less readable? I find it a lot more difficult to immediately parse than:

Re: [swift-evolution] [Pitch] Property reflection

Sent from my iPad > On May 27, 2016, at 11:26 AM, Austin Zheng wrote: > > Oh, this is really interesting. The idea being that you get an object > representing a property like "age" based on a metatype (like "Person.type"), > and then you pass in instances of the type

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

> Am 27.05.2016 um 18:28 schrieb Matthew Johnson : > > > > Sent from my iPad > > On May 27, 2016, at 11:18 AM, Austin Zheng > wrote: > >> Here's a strawman idea. >> >> What if we go with '&' and 'where', but we

[swift-evolution] Pitch: Small fix to where clauses in generics

Forgive me if this has already been proposed in one of the generics threads; I did a quick check and didn’t see anything. Currently, the code below does not compile: protocol P {} struct S: P {} extension SequenceType where Generator.Element: P { func foo() {} } func F(arr: [P]) {

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

Sent from my iPad > On May 27, 2016, at 11:18 AM, Austin Zheng wrote: > > Here's a strawman idea. > > What if we go with '&' and 'where', but we enclose the whole thing in > parentheses? > > (class & Protocol1 & Protocol2 where .Foo == Int, .Bar : Baz) > > There are

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

> Am 27.05.2016 um 17:15 schrieb L Mihalkovic : > > > > >> On May 27, 2016, at 4:52 PM, Matthew Johnson > > wrote: >> >>> >>> On May 27, 2016, at 7:20 AM, Thorsten Seitz via swift-evolution >>>

Re: [swift-evolution] [Pitch] Property reflection

Oh, this is really interesting. The idea being that you get an object representing a property like "age" based on a metatype (like "Person.type"), and then you pass in instances of the type to methods on that object to manipulate that property. That is definitely less stateful and less prone to

Re: [swift-evolution] [Idea] Switch Statement with Optional Binding

You can do it today (2.2 and 3.0-master) like this: switch cityIDs["Paris"] { case let .Some(parisCityID) where 0..<10 ~= parisCityID: print("Paris city ID: \(parisCityID)") default: break } > On May 27, 2016, at 1:58 AM, Natthan Leong via swift-evolution >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

Here's a strawman idea. What if we go with '&' and 'where', but we enclose the whole thing in parentheses? (class & Protocol1 & Protocol2 where .Foo == Int, .Bar : Baz) There are a couple of reasons I propose this syntax: - It makes it very clear where the definition of the type begins and

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

It would fail if not all members were Equatable or Hashable. If it was automatic, you wouldn’t get any warning or sign at all. If you have to explicitly conform to the protocols, then your intention is clear, and if an automatic implementation cannot be made (because not all members were

[swift-evolution] [Idea] Switch Statement with Optional Binding

Hi there, I was wondering if the community would like Swift to have a switch statement with optional binding. Take this simple dictionary as an example: let cityIDs = ["Paris": 1, "London": 2] Currently, this is how things are done if parisCityID is used only once within an if-let statement

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

Sent from my iPad > On May 27, 2016, at 11:07 AM, Thorsten Seitz wrote: > > >>> Am 27.05.2016 um 16:54 schrieb Matthew Johnson : >>> >>> >>> On May 27, 2016, at 8:18 AM, Thorsten Seitz via swift-evolution >>> wrote:

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

> Am 27.05.2016 um 16:54 schrieb Matthew Johnson : > >> >> On May 27, 2016, at 8:18 AM, Thorsten Seitz via swift-evolution >> > wrote: >> >> Personally I think `&` is more lightweight (and it is established

Re: [swift-evolution] [Pitch] Property reflection

> On 27 May 2016, at 10:43 PM, Matthew Johnson wrote: > >> >> On May 27, 2016, at 9:22 AM, Anders Ha > > wrote: >> >>> >>> On 27 May 2016, at 9:30 PM, Matthew Johnson >>

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

> On May 27, 2016, at 10:37 AM, plx via swift-evolution > wrote: > > >> On May 26, 2016, at 1:00 PM, T.J. Usiyan via swift-evolution >> > wrote: >> >> A `deriving` keyword, at the very least, is pretty

Re: [swift-evolution] Enhanced existential types proposal discussion

> On May 27, 2016, at 8:14 AM, Thorsten Seitz via swift-evolution > wrote: > > >> Am 27.05.2016 um 10:45 schrieb Austin Zheng > >: >> >> As far as I understand it (and the core team as well, judging from their

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

> On May 26, 2016, at 1:00 PM, T.J. Usiyan via swift-evolution > wrote: > > A `deriving` keyword, at the very least, is pretty explicitly *not* an > all-or-nothing situation. If you want to define equality/hashability for your > type manually, don't use `deriving`.

Re: [swift-evolution] Enhanced existential types proposal discussion

> On May 27, 2016, at 6:02 AM, L. Mihalkovic > wrote: > > > On May 26, 2016, at 10:56 PM, Matthew Johnson via swift-evolution > > wrote: > >> >>> On May 26, 2016, at 3:39 PM, Adrian Zubarev via

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

When would the automatic implementation fail? I see your point about adding to the compile size and I had previously mentioned that. Usually in the apps I develop that is not a concern. However I can see it could be a concern for apps that are more restrictive. If Swift is to be used to build

Re: [swift-evolution] Enhanced existential types proposal discussion

> On May 27, 2016, at 3:45 AM, Austin Zheng via swift-evolution > wrote: > > As far as I understand it (and the core team as well, judging from their > posts), an existential is just a type defined by an interface of some sort > ("there exists a type that is

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

> On May 27, 2016, at 7:08 AM, Thorsten Seitz wrote: > >> >> Am 25.05.2016 um 22:16 schrieb Matthew Johnson via swift-evolution >> >: >> >> >>> On May 25, 2016, at 2:22 PM, Brent Royal-Gordon

  1   2   >