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

> On May 31, 2016, at 1:59 PM, Adrian Zubarev via swift-evolution > wrote: > >> +1. This is example *is not* a single expression code block. There are 3 >> expressions (the condition, the return value in the else block, and the >> primary return value). > > The

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

-Matthew > > > > -- > Adrian Zubarev > Sent with Airmail > > Am 31. Mai 2016 um 18:33:09, Leonardo Pessoa via swift-evolution > (swift-evolution@swift.org <mailto:swift-evolution@swift.org>) schrieb: > >> +1 >> >> L >> >>

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

ssoa via swift-evolution >> (swift-evolution@swift.org <mailto:swift-evolution@swift.org>) schrieb: >> >>> +1 >>> >>> L >>> >>> On 31 May 2016 at 12:47, Matthew Johnson via swift-evolution >>> <swift-evolution@

Re: [swift-evolution] Ad hoc enums / options

I think I'm -1 on this. It makes things easier for the implementer of the function and harder for the caller. It's not clear whether the caller could store an argument to pass in a variable, but if they could they would need to list out all cases in the type of the variable (unless these

Re: [swift-evolution] Variadic generics discussion

gt;> wrote: >>>> >>>> >>>>> On May 31, 2016, at 9:16 AM, L Mihalkovic <laurent.mihalko...@gmail.com >>>>> <mailto:laurent.mihalko...@gmail.com>> wrote: >>>>> >>>>> >>>>> >>&

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

> On May 28, 2016, at 3:09 AM, David Hart via swift-evolution > wrote: > > It isn’t a special case because all other single-statement closures in the > language work that way. It’s actually inconsistent now. Computed properties aren’t closures so it’s not

Re: [swift-evolution] Variadic generics discussion

y 31, 2016, at 9:16 AM, L Mihalkovic <laurent.mihalko...@gmail.com >>> <mailto:laurent.mihalko...@gmail.com>> wrote: >>> >>> >>> >>>> On May 31, 2016, at 3:57 PM, Matthew Johnson via swift-evolution >>>> <swift-evolution@

Re: [swift-evolution] Variadic generics discussion

Austin, One very useful possibility opened up by variadic generics that you don’t mention is the ability to write extensions for structural types (tuple, function, maybe union in the future), including conforming them to protocols. This would be a separate proposal building on the capability

Re: [swift-evolution] [Pitch] Tuple Destructuring in Parameter Lists

Sent from my iPad On May 30, 2016, at 8:01 AM, Brent Royal-Gordon via swift-evolution wrote: >> // Allowed today: >> func takesATuple(tuple: (Int, Int)) { >> let valueA = tuple.0 >> let valueB = tuple.1 >> // ... >> } >> >> // Proposed syntax: >> func

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

Sent from my iPad > On May 29, 2016, at 10:22 PM, Charles Srstka wrote: > >> On May 29, 2016, at 10:13 PM, Matthew Johnson wrote: >> >> On May 29, 2016, at 9:43 PM, Charles Srstka wrote: >> On May 29, 2016,

Re: [swift-evolution] Variadic generics discussion

Sent from my iPad > On May 29, 2016, at 10:14 PM, Austin Zheng wrote: > > >> On May 29, 2016, at 8:04 PM, Matthew Johnson wrote: >> >> >> >> Sent from my iPad >> >>> On May 29, 2016, at 7:36 PM, Austin Zheng via swift-evolution >>>

Re: [swift-evolution] Variadic generics discussion

Sent from my iPad > On May 29, 2016, at 7:36 PM, Austin Zheng via swift-evolution > wrote: > > I significantly rewrote the proposal to take into account as much feedback as > I could. (Many things, like syntax, haven't been changed yet, but will be in > a

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

Sent from my iPad > On May 29, 2016, at 5:43 PM, Charles Srstka via swift-evolution > wrote: > >> On May 29, 2016, at 5:16 PM, Austin Zheng wrote: >> >> I think the problem here is that P == P is true, but P : P is not (a >> protocol does

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

Sent from my iPad > On May 29, 2016, at 9:12 AM, Vladimir.S via swift-evolution > wrote: > >> On 27.05.2016 18:37, plx via swift-evolution wrote: >> >>> On May 26, 2016, at 1:00 PM, T.J. Usiyan via swift-evolution >>>

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

Sent from my iPad > On May 29, 2016, at 8:41 AM, Vladimir.S via swift-evolution > wrote: > > Saw `class` in examples and want to clarify.. Are we discussing auto-deriving > for *value types only*. Or for classes also? > As I understand, there could be some

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

able compromise between separate 'deriving' decoration and > implicit derivation(when your type is Hashable without any conformance to > protocol, just if each property is Hashable). > >> On 29.05.2016 14:42, Matthew Johnson via swift-evolution wrote: >> >> >> S

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.

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

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

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 >

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

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:

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

t; 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 >> >> <https://github.com/austinzheng/swift-evolution/blob/az-existentials/proposals/-enhanced-

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

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

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

Sent from my iPad > On May 28, 2016, at 12:40 PM, Thorsten Seitz <tseit...@icloud.com> wrote: > > >>> Am 27.05.2016 um 20:47 schrieb Matthew Johnson via swift-evolution >>> <swift-evolution@swift.org>: >>> >>> >>>

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

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,

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 <clatt...@apple.com> wrote: > > On May 27, 2016, at 12:37 PM, Erica Sadun via swift-evolution > <swift-evolution@swift.org> wrote: >>>> On May 27, 2016, at 1:28 PM, Matthew Johnson via sw

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

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

ple lines. Not so with `guard`. > On Fri, May 27, 2016 at 20:37 Matthew Johnson via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > > > Sent from my iPad > > On May 27, 2016, at 7:22 PM, Erica Sadun <er...@

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] [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] [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] 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] [Draft] Automatically deriving Equatable and Hashable for certain value types

says "hey, is the default implementation going to do the right >> thing? Do you need to customize it for your struct?" But it's not a >> guarantee either. And if it's not a guarantee then should it be automatic >> then? Most developer will go with the default implement

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

ly why opting in is the right way to go. It may not prevent all developers 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`. > > >>>

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] [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] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

> On May 27, 2016, at 2:37 PM, Erica Sadun <er...@ericasadun.com> wrote: > > >> On May 27, 2016, at 1:28 PM, Matthew Johnson via swift-evolution >> <swift-evolution@swift.org> wrote: >> >>> • What is your evaluation of the proposa

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

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

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

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] [Draft] Automatically deriving Equatable and Hashable for certain value types

of equality for their type. > > >> On May 26, 2016, at 11:35 AM, Matthew Johnson via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >>> >>> On May 26, 2016, at 10:18 AM, T.J. Usiyan via swift-ev

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

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>

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] [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] Enhanced existential types proposal discussion

> On May 27, 2016, at 6:02 AM, L. Mihalkovic <laurent.mihalko...@gmail.com> > wrote: > > > On May 26, 2016, at 10:56 PM, Matthew Johnson via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > >> >>>

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 <tseit...@icloud.com> wrote: > >> >> Am 25.05.2016 um 22:16 schrieb Matthew Johnson via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>: >> >> &

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

> 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

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

> On May 27, 2016, at 3:57 AM, Thorsten Seitz <tseit...@icloud.com> wrote: > >> >> Am 25.05.2016 um 17:03 schrieb Matthew Johnson via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>: >> >> >>>

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

> On May 27, 2016, at 9:50 AM, L Mihalkovic <laurent.mihalko...@gmail.com> > wrote: > >> >> On May 27, 2016, at 4:05 PM, Matthew Johnson via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >&g

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

> 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

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

> 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

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

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

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

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

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

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

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

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

Sent from my iPad > On May 27, 2016, at 3:07 AM, L. Mihalkovic <laurent.mihalko...@gmail.com> > wrote: > > > >> On May 27, 2016, at 4:20 AM, Matthew Johnson via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> >>> O

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

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

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

r. '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-evolution/blob/az-existentials/pr

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

wift one day) we would > have: > > switch a { > case is C: … > case is D: … > case is E: … > } > > >> >>> >>> >>>> But it is also overly restrictive. There are valid cases where you might >>>> want an exhaustive switch for a sea

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

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

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

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

t;>>> the proposed feature requires much less. And you're thinking only >>>>>>>>>>>> about the restrictive set (internal and private) and forgetting >>>>>>>>>>>> the more open end (public). Why is it so bad for this proposal to

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

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

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

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

't disjoint. I don't think that solution is appropriate to Swift. > > -Thorsten > > >> Am 25.05.2016 um 19:49 schrieb Matthew Johnson via swift-evolution >> <swift-evolution@swift.org>: >> >> >> >> Sent from my iPad >> >>> On

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

ike 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. You could also have an object that would have to >>>>>>> handle a large

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

ional 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

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 >> <swift-evolution@swift.org> wrote: >> >> >> Sent from

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

gt;>>>> inference/context awareness in the language - not less! >>>>> >>>>> l8r >>>>> Sean >>>>> >>>>> Sent from my iPad >>>>> >>>>>> On May 25, 2016, at 5:37 PM, Leonardo

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

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

>>>> >>>>>> Austin >>>>>> >>>>>>> On Tue, May 24, 2016 at 1:29 PM, Leonardo Pessoa <m...@lmpessoa.com> >>>>>>> wrote: >>>>>>> I like this but I think it would be a lot hard to ensure you h

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

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

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

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:

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

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

onforming types. >>>>>>>>>> >>>>>>>>>> Sent from my iPhone >>>>>>>>>> >>>>>>>>>> On May 24, 2016, at 15:35, Austin Zheng via swift-evolution >>>>>>

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

olution >>>>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>>>>>>> >>>>>>>>> If you pattern match on a type that is declared internal or private, >>>>>>>&

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

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

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

t can check against. >>>>>>> >>>>>>> Austin >>>>>>> >>>>>>>> On Tue, May 24, 2016 at 1:29 PM, Leonardo Pessoa <m...@lmpessoa.com> >>>>>>>> wrote: >>>>>>>>

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

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

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

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

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

ases >>>>> 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 for this but these should be open-ended like strings >>>>> and requir

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

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

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

ses >>>>> 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 for this but these should be open-ended like strings >>>>> and requ

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

t; subclasses covered. Think of frameworks that could provide many >>>>>> 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 ex

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