Re: [swift-evolution] Variadic generics discussion

Sent from my iPad > On May 29, 2016, at 1:22 AM, Austin Zheng wrote: > > Thank you for reading through the proposal! > >> On May 28, 2016, at 7:41 PM, Matthew Johnson wrote: >> >> These are some very good and clearly articulated examples. Great work! >> This section is important because

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

Sent from my iPad > On May 29, 2016, at 12:28 AM, Patrick Smith wrote: > > Yeah I don’t see a problem. It’s the same way that protocol extensions just > work. Think of this automatic synthesis as a really flexible protocol > extension: > > extension Hashable where Members : Hashable { > v

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

> On May 28, 2016, at 9:29 PM, Brent Royal-Gordon > wrote: > >>> You are trying to call `mutating` methods on an *immutable* value, the >>> return value of `withCopy`. Normally, the compiler would reject that. >> >> You are right, there would need to be an exception for method cascades. >>

Re: [swift-evolution] Variadic generics discussion

> On May 28, 2016, at 3:03 PM, Austin Zheng via swift-evolution > wrote: > > Hello swift-evolution, > > I put together a draft proposal for the variadic generics feature described > in "Completing Generics" as a major objective for Swift 3.x. It can be found > here: Austin, this is really e

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

> On May 27, 2016, at 7:19 PM, Brent Royal-Gordon > wrote: > >>> - A plain `with` whose closure parameter is not mutable and which is marked >>> `@discardableResult`. >> >> I would like to see this version restricted to AnyObject. It has extremely >> limited utility with value types. It wo

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

> On May 28, 2016, at 8:43 PM, Pedro Vieira via swift-evolution > wrote: > > I really think this would be a great addition to Swift. Although, I don't see > the need to use a new keyword `deriving` for this feature. > The following would be enough: > > struct Foo: Equatable, Hashable { > ..

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

based on the constraints defined earlier. 'as?' can also be used for >> conditional casting of these anonymously-typed values into potential actual >> types. >> >> As always, the link is here, and feedback would be greatly appreciated: >> https://github

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

istentials >> based on the constraints defined earlier. 'as?' can also be used for >> conditional casting of these anonymously-typed values into potential actual >> types. >> >> As always, the link is here, and feedback would be greatly appreciated:

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

Sent from my iPad > On May 28, 2016, at 12:33 PM, Chris Lattner wrote: > > >> On May 28, 2016, at 10:18 AM, Matthew Johnson wrote: >> Given the whole newline groundswell that has emerged on SE, I did consider it but when I mocked up examples, it felt less readable and I sus

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

Sent from my iPad > On May 28, 2016, at 1:38 PM, Haravikk via swift-evolution > wrote: > > >> On 27 May 2016, at 15:31, plx via swift-evolution >> wrote: >> >> protocol Sequence { >> typealias of == S: Self where S.Iterator.Element == E >> } >> >> // sequence-accepting variant

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

Sent from my iPad > On May 28, 2016, at 12:40 PM, Thorsten Seitz wrote: > > >>> Am 27.05.2016 um 20:47 schrieb Matthew Johnson via swift-evolution >>> : >>> >>> >>>> On May 27, 2016, at 12:05 PM, Charles Srstka via swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol syntax with Any

Sent from my iPad > On May 28, 2016, at 12:50 PM, Thorsten Seitz wrote: > > >> Am 28.05.2016 um 19:35 schrieb Austin Zheng : >> >> Sorry, 'with' in the second example should be 'where'. My personal >> preference is to keep 'where' for both uses, since they are serving the same >> purpose.

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

Sent from my iPad > On May 28, 2016, at 12:11 PM, Chris Lattner wrote: > > On May 27, 2016, at 12:37 PM, Erica Sadun via swift-evolution > wrote: >>>> On May 27, 2016, at 1:28 PM, Matthew Johnson via swift-evolution >>>> wrote: >>>&

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

Sent from my iPad > On May 27, 2016, at 10:08 PM, Patrick Smith via swift-evolution > wrote: > > 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

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

guard`. > On Fri, May 27, 2016 at 20:37 Matthew Johnson via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > > > Sent from my iPad > > On May 27, 2016, at 7:22 PM, Erica Sadun <mailto:er...@ericasadun.com>> wrote: > >> &g

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 retaining commas as separators within clauses (as >>>

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 semicolons, and this >> proposal seems to use/require the

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 doesn't have anything to do

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 prefer this direction. > >

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). >>> >>> In the future we may have user-defined a

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

>> until later that the default implementation would be wrong for your >> fancy/unusual struct. It is likely that opting in may raise a flag in your >> brain that says "hey, is the default implementation going to do the right >> thing? Do you need to customize it for

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

ers from such mistakes, but it might help some, especially those who understand the issues involved but may *forget* to consider the issues if they don’t have to type `deriving Equatable, Hashable`. > > >>> >>> >>>> On May 26, 2016, at 11:35 AM, Matthew J

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: >> >>On Tue, May 24, 2016 at 4:24 PM, Brent Royal-Gordon >> wrote: >> >>> I

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 describing. >> >> The reas

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 condi

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol syntax with Any

> 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 else disagrees). I’ve b

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 w

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol syntax with Any

> 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 > >: >> >> I think the parentheses are the fundamental aspe

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol syntax with Any

> 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 question around. If tuples we

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

; > >> On May 26, 2016, at 11:35 AM, Matthew Johnson via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >>> >>> On May 26, 2016, at 10:18 AM, T.J. Usiyan via swift-evolution >>> mailto:swift-evolution@swift.org>> wrot

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 >> mailto:swift-evolution@swift.org>> wrote: >> >> For the Sequence/Collection it’s a lot of work for IMHO a rather minor >> convenience, but for more-complex

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 talking about them if they wi

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 to methods on that objec

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol syntax with Any

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 a couple of reasons I p

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol syntax with Any

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: >>> >>> Personally I think `&` is more lightweight (and it is establishe

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 >> mailto:swift-evolution@swift.org>> wrote: >> >> A `deriving` keyword, at the very least, is pretty explicitly *not* an >> all-or-nothing situation. If you

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 >> posts), an existential is just a type defined by

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 > mailto:swift-evolution@swift.org>> wrote: > >> >>> On May 26, 2016, at 3:39 PM, Adrian Zubarev via swift-evolution &g

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 capable of X, Y, and Z"), and you

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol syntax with Any

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol syntax with Any

> On May 27, 2016, at 6:16 AM, Thorsten Seitz wrote: > > >> Am 25.05.2016 um 21:22 schrieb Brent Royal-Gordon via swift-evolution >> : >> >>> But if we are going to remove the ability to use typealiases bound to `Any` >>> in constraints we need to introduce an alternative mechanism for facto

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol syntax with Any

> On May 27, 2016, at 3:57 AM, Thorsten Seitz wrote: > >> >> Am 25.05.2016 um 17:03 schrieb Matthew Johnson via swift-evolution >> mailto:swift-evolution@swift.org>>: >> >> >>> On May 25, 2016, at 9:59 AM, L. Mihalkovic via swift-evol

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

> On May 27, 2016, at 9:50 AM, L Mihalkovic > wrote: > >> >> On May 27, 2016, at 4:05 PM, Matthew Johnson via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> >> >> Sent from my iPad >> >> On May 26, 2

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol syntax with Any

> On May 27, 2016, at 8:18 AM, Thorsten Seitz via swift-evolution > wrote: > > Personally I think `&` is more lightweight (and it is established in other > languages like Ceylon and Typescript) and `where` is more expressive (and > established in Swift for introducing constraints), so I would

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol syntax with Any

> On May 27, 2016, at 7:20 AM, Thorsten Seitz via swift-evolution > wrote: > > From the point of view of the type system `P & Q` is an anonymous supertype > of `P` and `Q`. > This would be just the same if the syntax was `Any`. I don’t see a > semantic difference here. > > Whether that is a

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

> On May 27, 2016, at 9:22 AM, Anders Ha wrote: > >> >> On 27 May 2016, at 9:30 PM, Matthew Johnson > > wrote: >> >> >> >> Sent from my iPad >> >> On May 27, 2016, at 5:45 AM, Anders Ha via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >>>

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

Sent from my iPad > On May 26, 2016, at 9:44 PM, Austin Zheng wrote: > > Thanks, as always, for the thoughtful feedback. (inline) > >> On Thu, May 26, 2016 at 7:20 PM, Matthew Johnson >> wrote: >> >> >> These names are a good place to start but I agree that it would be nice to >> improve

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

Sent from my iPad On May 27, 2016, at 5:25 AM, Brent Royal-Gordon wrote: >> This one is tricky. I am generally be opposed to any way to get around >> access control. But people are going to implement things like serialization >> using this which may require access to private properties. I

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

Sent from my iPad > On May 27, 2016, at 8:25 AM, Charlie Monroe wrote: > >> This one is tricky. I am generally be opposed to any way to get around >> access control. But people are going to implement things like serialization >> using this which may require access to private properties. I

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

Sent from my iPad > On May 27, 2016, at 6:15 AM, Leonardo Pessoa wrote: > > I'm also not fond of allowing what could be called a backdoor to accessing > privates and intervals too but has anyone thought of enhancing the Mirror > class instead of having something totally new? I've tried using

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

Sent from my iPad > On May 27, 2016, at 5:45 AM, Anders Ha via swift-evolution > wrote: > > I wonder how the views would work with the value semantic of structs. Not all value types have value semantics. It's important to not forget that. I would like to see a way to make that distinction

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

Sent from my iPad > On May 27, 2016, at 2:25 AM, Austin Zheng wrote: > > Would you be willing to elaborate? Are you thinking of model objects whose > properties are all completely hidden using 'private' and whose APIs are > available only through methods? What if there existed something like

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

Sent from my iPad > On May 27, 2016, at 3:07 AM, L. Mihalkovic > wrote: > > > >> On May 27, 2016, at 4:20 AM, Matthew Johnson via swift-evolution >> wrote: >> >> >>> On May 26, 2016, at 8:25 PM, Austin Zheng via swift-evolution >&

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

> On May 26, 2016, at 8:25 PM, Austin Zheng via swift-evolution > wrote: > > Hi swift-evolution, > > For those who are interested I'd like to present a pre-pre-proposal for > reflection upon a type's properties and solicit feedback. > > First of all, some caveats: this is only a very small

Re: [swift-evolution] [Proposal] Enums with static stored properties for each case

> On May 26, 2016, at 4:47 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> The proposed solution is to have single static initializer for each >> enum case that initializes stored properties. For example, > > My opinions so far: > > - Abusing rawValue is just that: an abuse. > > - U

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

> On May 26, 2016, at 3:39 PM, Adrian Zubarev via swift-evolution > wrote: > >>> I alway enjoy hearing your ideas. >>> >>> This is quite interesting. It's basically a way to define an ad-hoc >>> interface that a type doesn't need to explicitly declare it conforms to. I >>> know Golang works

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

Sent from my iPad > On May 26, 2016, at 2:49 PM, Austin Zheng via swift-evolution > wrote: > > I alway enjoy hearing your ideas. > > This is quite interesting. It's basically a way to define an ad-hoc interface > that a type doesn't need to explicitly declare it conforms to. I know Golang

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

nts defined earlier. 'as?' can also be used for >> conditional casting of these anonymously-typed values into potential actual >> types. >> >> As always, the link is here, and feedback would be greatly appreciated: >> https://github.com/austinzheng/swift-evolu

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

Sent from my iPad > On May 26, 2016, at 12:20 PM, L. Mihalkovic via swift-evolution > wrote: > > what i care about is to have a choice about what DEFINES the identity of my > values, not just an all-or-nothing situation. I'm sure nobody would object if you offers suggestions. I have some t

Re: [swift-evolution] [Pitch] Exhaustive pattern matching forprotocols and classes

rly restrictive. There are valid cases where you might >>>> want an exhaustive switch for a sealed hierarchy that has concrete parent >>>> classes. >>> >>> In that case your suggestion of `isExactly` (or something shorter :-) would >>> indeed be the solutio

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

struct S: P { typealias P.Element = Foo } > > Austin > >> On May 26, 2016, at 8:00 AM, Matthew Johnson via swift-evolution >> wrote: >> >> >>> On May 26, 2016, at 9:54 AM, Jan E. Schotsman via swift-evolution >>> wrote: &g

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

but without ever revealing the actual >>>> type. There is no need anymore to limit the APIs exposed to the user, >>>> although there may still exist APIs that are semantically useless without >>>> additional type information. >>>> >>>> A

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

> On May 26, 2016, at 10:18 AM, T.J. Usiyan via swift-evolution > wrote: > > +1 to a `deriving` keyword + 1. I like it as well. It makes the feature opt-in, declaring conformance and requesting synthesis at the same time. The syntactic difference from a simple conformance declaration mean

Re: [swift-evolution] [Pitch] Exhaustive pattern matching forprotocols and classes

t; > -Thorsten > > > >> >> If you want all non-leaf types to be abstract you should probably consider >> using protocols in Swift. >> >>> >>> Example in Ceylon: >>> abstract class Parent() of Child1 | Child2 {} >>> >>

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

> On May 26, 2016, at 9:54 AM, Jan E. Schotsman via swift-evolution > wrote: > > In the "where clause" section, shouldn't this be allowed: > > let a : Any SetAlgebraType.Element> > > I am asking because the acceptable type equality constraint is stated as: > > Type equality constraint: X ==

Re: [swift-evolution] [Pitch] Exhaustive pattern matching forprotocols and classes

ass Grandchild2() extends Child2() {} > > void main() { > Parent foo = Child1(); > > switch (foo) > case (is Child1) { > print("Child1"); > } > case (is Grandchild1) { > print("Grandchild1"); > } > case (is Grandchild

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

> On May 26, 2016, at 8:51 AM, Jan E. Schotsman via swift-evolution > wrote: > > > On May 26, 2016, at 3:44 PM, Austin Zheng wrote: > >> The inimitable Joe Groff provided me with an outline as to how the design >> could be improved. I've taken the liberty of rewriting parts of the >> proposal

Re: [swift-evolution] [Pitch] Remove associated type inference

Sent from my iPad > On May 26, 2016, at 1:21 AM, David Hart via swift-evolution > wrote: > > We could have the generic type parameter always shadow the associated type. I believe there has been talk of automatically introducing an associated type corresponding to generic parameters. I'm no

Re: [swift-evolution] [Pitch] Exhaustive pattern matching forprotocols and classes

that solution is appropriate to Swift. > > -Thorsten > > >> Am 25.05.2016 um 19:49 schrieb Matthew Johnson via swift-evolution >> : >> >> >> >> Sent from my iPad >> >>> On May 25, 2016, at 12:41 PM, Charlie Monroe &

Re: [swift-evolution] [Pitch] Exhaustive pattern matching for protocols and classes

016 at 1:29 PM, Leonardo Pessoa >>>>>>> wrote: >>>>>>> I like this but I think it would be a lot hard to ensure you have all >>>>>>> subclasses covered. Think of frameworks that could provide many >>>>&

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

casting of these anonymously-typed values into potential actual >> types. >> >> As always, the link is here, and feedback would be greatly appreciated: >> https://github.com/austinzheng/swift-evolution/blob/az-existentials/proposals/-enhanced-existentials.md >>

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

Int attempt is a compiler error because there is no possibility for the attempted cast to succeed (if that is what you intend). > > Best, > Austin > >> On Tue, May 24, 2016 at 5:09 AM, Matthew Johnson via swift-evolution >> wrote: >> >> >> Sent f

Re: [swift-evolution] [Pitch] Remove associated type inference

gt; l8r >>>>> Sean >>>>> >>>>> Sent from my iPad >>>>> >>>>>> On May 25, 2016, at 5:37 PM, Leonardo Pessoa via swift-evolution >>>>>> wrote: >>>>>> >>>>>> -1. I don&#

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

Sent from my iPad On May 25, 2016, at 8:08 PM, Brent Royal-Gordon via swift-evolution wrote: >> Omission of fields from generated computations >> >> Should it be possible to easily omit certain properties from automatically >> generated equality tests or hash value computation? This could b

Re: [swift-evolution] [Pitch] Exhaustive pattern matching for protocols and classes

;>> If you pattern match on a type that is declared internal or private, it >>>>>> is impossible for the compiler to not have an exhaustive list of >>>>>> subclasses that it can check against. >>>>>> >>>>>> Austin &g

Re: [swift-evolution] [Pitch] Remove associated type inference

Sent from my iPad > On May 25, 2016, at 6:11 PM, Dmitri Gribenko via swift-evolution > wrote: > >> On Wed, May 25, 2016 at 3:42 PM, Leonardo Pessoa wrote: >>> On Wednesday, 25 May 2016, Dmitri Gribenko via swift-evolution >>> wrote: >>> On Wed, May 25, 2016 at 2:52 PM, David Hart wrote: >

Re: [swift-evolution] [Pitch] Remove associated type inference

I agree that if we’re going to do it we should probably do it in Swift 3. But it is a very convenient and useful feature that significantly lowers the bar of conforming to protocols with associated types (in many cases you can just implement the required members without thinking about the assoc

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

> On May 25, 2016, at 4:31 PM, Erica Sadun wrote: > > >> On May 25, 2016, at 3:29 PM, Matthew Johnson > > wrote: >> On May 25, 2016, at 3:56 PM, Erica Sadun > > wrote: >>> I wouldn't be pushing if I thought it wouldn't be useful after

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

Sent from my iPad > On May 25, 2016, at 3:56 PM, Erica Sadun wrote: > >> On May 25, 2016, at 2:55 PM, Matthew Johnson wrote: >> >> >>> On May 25, 2016, at 3:48 PM, Jacob Bandes-Storch via swift-evolution >>> wrote: >>> >>> I like this pretty well, and I think "with()" makes sense as a pe

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

> On May 25, 2016, at 3:48 PM, Jacob Bandes-Storch via swift-evolution > wrote: > > I like this pretty well, and I think "with()" makes sense as a peer of > "withUnsafePointer()", "withExtendedLifetime()", etc. > > I'd also be okay with waiting for a comprehensive method-cascading solution.

Re: [swift-evolution] [Pitch] Exhaustive pattern matching forprotocols and classes

t;> >>>>>>>>>> Sent from my iPhone >>>>>>>>>> >>>>>>>>>> On May 24, 2016, at 15:35, Austin Zheng via swift-evolution >>>>>>>>>> mailto:swift-evolution@swift.org>> wrote:

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol syntax with Any

> On May 25, 2016, at 2:22 PM, Brent Royal-Gordon > wrote: > >> But if we are going to remove the ability to use typealiases bound to `Any` >> in constraints we need to introduce an alternative mechanism for factoring >> out constraints (hopefully a superior mechanism that can abstract over

Re: [swift-evolution] [Pitch] Exhaustive pattern matching forprotocols and classes

ion >>>>>>>> mailto:swift-evolution@swift.org>> wrote: >>>>>>>> >>>>>>>>> If you pattern match on a type that is declared internal or private, >>>>>>>>> it is impossible for the compiler to not have a

Re: [swift-evolution] [Pitch] Exhaustive pattern matching forprotocols and classes

> On May 25, 2016, at 1:09 PM, Xiaodi Wu wrote: > > On Wed, May 25, 2016 at 12:49 PM, Matthew Johnson via swift-evolution > mailto:swift-evolution@swift.org>>wrote: > > > Sent from my iPad > > On May 25, 2016, at 12:41 PM, Charlie Monroe <mail

Re: [swift-evolution] [Pitch] Exhaustive pattern matching forprotocols and classes

gt;>> >>>>>>> Austin >>>>>>> >>>>>>>> On Tue, May 24, 2016 at 1:29 PM, Leonardo Pessoa >>>>>>>> wrote: >>>>>>>> I like this but I think it would be a lot hard to ensure you have all >>&g

Re: [swift-evolution] [Review] SE-0089: Replace protocol syntax with Any

Sent from my iPad > On May 25, 2016, at 12:28 PM, Dmitri Gribenko via swift-evolution > wrote: > > I like the direction about creating a unified syntax for current > implementation of existentials and future generalized existentials. I > am concerned about the chosen syntax though, I don't t

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol syntax with Any

Sent from my iPad > On May 25, 2016, at 12:10 PM, Jordan Rose via swift-evolution > wrote: > > >>> On May 25, 2016, at 05:27, Brent Royal-Gordon via swift-evolution >>> wrote: >>> >>> AFAIK an existential type is a type T with type parameters that are still >>> abstract (see for example

Re: [swift-evolution] [Pitch] Exhaustive pattern matching forprotocols and classes

gt;>>>> unsealed classes. You could also have an object that would have to >>>>> handle a large subtree (NSObject?) and the order in which the cases >>>>> are evaluated would matter just as in exception handling in languages >>>>> such as Ja

Re: [swift-evolution] [Pitch] Exhaustive pattern matching forprotocols and classes

gt;> handle a large subtree (NSObject?) and the order in which the cases >>>>> are evaluated would matter just as in exception handling in languages >>>>> such as Java (or require some evaluation from the compiler to raise >>>>> warnings). I'm +1

Re: [swift-evolution] [Pitch] Exhaustive pattern matching for protocols and classes

evaluation from the compiler to raise >>>>> warnings). I'm +1 for this but these should be open-ended like strings >>>>> and require the default case. >>>>> >>>>> On 24 May 2016 at 17:08, Austin Zheng via swift-evolution >>>&

Re: [swift-evolution] [Pitch] Exhaustive pattern matching forprotocols and classes

29 PM, Leonardo Pessoa >>>>>> wrote: >>>>>> I like this but I think it would be a lot hard to ensure you have all >>>>>> subclasses covered. Think of frameworks that could provide many >>>>>> unsealed classes. Y

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol syntax with Any

> On May 25, 2016, at 10:28 AM, L. Mihalkovic > wrote: > > > > On May 25, 2016, at 5:03 PM, Matthew Johnson > wrote: > >> >>> On May 25, 2016, at 9:59 AM, L. Mihalkovic via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> On May

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol syntax with Any

> On May 25, 2016, at 3:01 AM, Austin Zheng via swift-evolution > wrote: > > I am not going to comment on the proposal (conflict of interest etc). I do > want to speak up in support of Brent's points, though. > >> On May 25, 2016, at 12:34 AM, Brent Royal-Gordon via swift-evolution >> wrote

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol syntax with Any

> On May 25, 2016, at 9:59 AM, L. Mihalkovic via swift-evolution > wrote: > >> >> On May 25, 2016, at 10:01 AM, Austin Zheng via swift-evolution >> wrote: >> >> I am not going to comment on the proposal (conflict of interest etc). I do >> want to speak up in support of Brent's points, thou

Re: [swift-evolution] [Pitch] Exhaustive pattern matching forprotocols and classes

bject that would have to >>> handle a large subtree (NSObject?) and the order in which the cases >>> are evaluated would matter just as in exception handling in languages >>> such as Java (or require some evaluation from the compiler to raise >>> warni

Re: [swift-evolution] [Review] SE-0091: Improving operator requirements in protocols

Sent from my iPad > On May 25, 2016, at 12:18 AM, Thorsten Seitz wrote: > > > >> Am 18.05.2016 um 23:20 schrieb Matthew Johnson via swift-evolution >> : >> >> >>> On May 18, 2016, at 4:06 PM, Tony Allevato wrote: >>> >>

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol syntax with Any

Sent from my iPad > On May 25, 2016, at 1:33 AM, L. Mihalkovic > wrote: > > > >> On May 25, 2016, at 1:15 AM, Matthew Johnson via swift-evolution >> wrote: >> >> >> >> Sent from my iPad >> >> On May 24, 2016, at 6:09 PM,

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

Sent from my iPad > On May 24, 2016, at 9:35 PM, Austin Zheng wrote: > > > >> On Tue, May 24, 2016 at 4:24 PM, Brent Royal-Gordon >> wrote: >> > I’m not sure what you mean about introducing type unsafely. >> >> What I mean is that once you do this: >> >> let x: AnyCollection = my

Re: [swift-evolution] [Pitch] Exhaustive pattern matching for protocols and classes

from the compiler to raise >>> warnings). I'm +1 for this but these should be open-ended like strings >>> and require the default case. >>> >>> On 24 May 2016 at 17:08, Austin Zheng via swift-evolution >>> wrote: >>> > I have

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol syntax with Any

> On May 24, 2016, at 7:45 PM, Brent Royal-Gordon > wrote: > >> I believe it was things like "+" and "-" for set union and subtraction, etc. > > > That, or &, |, and ^, by analogy with bitwise operators. It definitely came > up during the SetAlgebra discussions. Another thread I guess I di

<    6   7   8   9   10   11   12   13   14   15   >