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

> On May 24, 2016, at 5:55 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> Better support for existentials (see the generics manifesto, >> https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md) should >> obviate the need for any sort of sugar or compiler magic to do th

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

Sent from my iPad On May 24, 2016, at 6:09 PM, Brent Royal-Gordon via swift-evolution wrote: >> If we're going to repaint this bikeshed, I think we should also consider as >> an alternative some form of infix syntax for composing constraints. Rust >> uses `P1 + P2`, and various C++ proposal

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

> On May 24, 2016, at 6: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 = myArrayOfCharacters > let y: AnyCollection = myString.characters > > Both `x` and `y` h

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

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] [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] [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] [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] [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] [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] [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 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] [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] [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

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 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] [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] [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] [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] [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

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] [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

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] [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] 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 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] 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] 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] 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] [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] 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] 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] 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] [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] [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] 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] 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] 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 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

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] [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] 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] 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] [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] [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] 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] 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

> 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] [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] [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] [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

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

> 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] [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] [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] [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 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] [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 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] 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] 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 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] [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] [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] [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] [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] [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] [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] [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] [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] [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-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 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

> 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] [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] [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] [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] [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] [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] [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] 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] [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] [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

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] [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] [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] [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] [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] [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] [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] 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] 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] [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] [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] 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

<    1   2   3   4   5   6   7   8   9   10   >