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

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

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

> On 27 May 2016, at 04:44, Austin Zheng via swift-evolution > wrote: > > My personal preference would be to honor access control, and consider ser/de > separately (especially since there are so many other possible considerations > for that feature). Access control in Swift isn't just anothe

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

Regards (From mobile) > On May 27, 2016, at 6:27 AM, David Sweeris via swift-evolution > wrote: > > +1 for "deriving", "synthesizes", or some other keyword. How are we going to > tell the compiler what protocols can participate? Something like > "@memberwise" is all I can think of, but I'm

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

> On 27 May 2016, at 2:40 PM, Austin Zheng via swift-evolution > wrote: > > Any of the NSObject subclass candidates may require their `description`s to > be altered to meet the semantics, which may or may not be an acceptable > breaking change. Do you think it might be worth changing `descri

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

> On 26 May 2016, at 5:40 PM, David Hart wrote: > > I’ve always found those two confusing. But I guess that > CustomDebugStringConvertible could provide more information, like the actual > type and pointer value. For example, imagine that we make UIColor > ValuePreservingStringConvertible, on

Re: [swift-evolution] [PITCH] ADD AN @RESTRICTED DECLARATION ATTRIBUTE

Are we back in a position where a different attribute (back to @restricted or similar keyword) would clear up the readability concerns? The current equivalent in @available terms: Short form: @available(OSX 10.8, iOS 8.0, *) @available(tvOS, unavailable) @available(watchO

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

I think this is an incredible idea. Should we eventually prepare an updated proposal? Given the need for further discussion I'd be happy to drive it forward, or if someone else wants they can take over too. (inline) > On May 25, 2016, at 10:08 PM, Chris Lattner wrote: > > Proposal Link: > h

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

+1 for "deriving", "synthesizes", or some other keyword. How are we going to tell the compiler what protocols can participate? Something like "@memberwise" is all I can think of, but I'm too tired for deep thought at the moment. - Dave Sweeris > On May 26, 2016, at 21:57, Ricardo Parada via swi

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

As Steve Jobs once said when demoing Interface Builder during the NeXT days: "The line of code you don't have to write is the line of code you don't have to debug." P.S. I hope I got the quote right, but that was the idea. :-) Sent from my iPhone > On May 25, 2016, at 10:02 PM, Patrick Sm

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

I like this. I don't see why not make this the default. If someone thinks it is not needed for their application then they simply don't use it. Having it there would not cause any harm. Unless someone had a requirement to have strict control on the size of the application and had to cut d

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

Thank you! If you have other ideas I'd love to hear them, even if they're completely different. I think this is a topic that deserves to 'simmer' for a while. You bring up an important point: should reflection be opt-in or opt-out? I've seen arguments for both options, and I think it's definitely

Re: [swift-evolution] [PITCH] ADD AN @RESTRICTED DECLARATION ATTRIBUTE

> What I'm saying here is that even if you accept that the asterisk means all > platforms, it does not follow that another argument in the same place should > refer to the platform names *listed in the attribute*. That's not at all > precedented in the meaning of the asterisk. The problem is, t

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

I don’t understand why you couldn’t conform to Equatable, and if it fulfils the requirements (all members are also Equatable), then its implementation is automatically created for you. That way you don’t need a new keyword. It’s like Objective-C’s property automatic synthesising that get used un

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

I wonder if synthesizes would be a better choice than deriving. > On May 26, 2016, at 5:58 AM, Michael Peternell via swift-evolution > wrote: > > Can we just copy&paste the solution from Haskell instead of creating our own? > It's just better in every aspect. Deriving `Equatable` and `Has

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

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 them. I will give it some thought. One comment for now - you use > both `get` / `set` and

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

This is important and really useful. There's a lot to like here. I have been thinking about property reflection recently too. Don't have time to write too much on it now, but was wondering what was the thinking behind suggesting an opt-in? For me, I would hope that getting access to a single proper

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] ADD AN @RESTRICTED DECLARATION ATTRIBUTE

On Thu, May 26, 2016 at 8:37 PM, Stuart Breckenridge < stuart.breckenri...@icloud.com> wrote: > I disagree. If you look the S > wift 2.2 guide: > > "You can also use an asterisk (*) to indicate availability of the > declaration on all of the platform names listed above." > > What this proposal wou

Re: [swift-evolution] [PITCH] ADD AN @RESTRICTED DECLARATION ATTRIBUTE

I disagree. If you look the S wift 2.2 guide: "You can also use an asterisk (*) to indicate availability of the declaration on all of the platform names listed above." What this proposal would add is: "Alternatively, you can use the word 'only' to indicate that the declaration is only availabl

[swift-evolution] [Pitch] Property reflection

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 piece of what reflection in Swift might look like one day, and it's certainly not the only po

Re: [swift-evolution] [PITCH] ADD AN @RESTRICTED DECLARATION ATTRIBUTE

On Thu, May 26, 2016 at 7:37 PM, Stuart Breckenridge via swift-evolution < swift-evolution@swift.org> wrote: > On reflection, I think the introduction of a new argument to limit > platform scope is superior — one less attribute to know about. > > I've revised the proposal draft: > https://github.c

Re: [swift-evolution] [PITCH] ADD AN @RESTRICTED DECLARATION ATTRIBUTE

On reflection, I think the introduction of a new argument to limit platform scope is superior — one less attribute to know about. I've revised the proposal draft: https://github.com/stuartbreckenridge/swift-evolution/blob/master/proposals/-add-only-declaration-argument.md

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: > > - Abusing rawValue is just that: an abuse. In addition, enums with associated types can’t have rawValues. Why is this relevant, you may ask? Because error enums are a huge use case for something like this. Bein

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] [Proposal] Enums with static stored properties for each case

> 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. - Using `where` just doesn't match the use of `where` elsewhere in the language; everywhere else, it'

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

While not as nice, Vladimir’s colon suggestion could work. :g() Reminds a bit of C++ but not bad. > On May 26, 2016, at 2:05 PM, Brent Royal-Gordon > wrote: > >> * Already very similar notation for enums where you leave off the entity >> name when it can be implied. > > That's the problem. L

Re: [swift-evolution] [Proposal] Enums with static storedpropertiesforeach case

On 26.05.2016 23:03, Leonardo Pessoa wrote: I get it and think this was really very interesting in Delphi and I wouldn't mind having something like this in Swift. But despite being able to extend associated information through the use of another array we'd still have more verbosity and scattering

Re: [swift-evolution] [Pitch] Add `mapValues` method to Dictionary

> On May 26, 2016, at 4:23 PM, Dave Abrahams via swift-evolution > wrote: > > > on Tue May 24 2016, Nate Cook wrote: > >>> On May 24, 2016, at 7:43 AM, Matthew Johnson via swift-evolution >>> wrote: >>> >>> Sent from my iPad >>> On May 24, 2016, at 12:59 AM, Brent Royal-Gordon via s

Re: [swift-evolution] [Idea] A 128-bit unsigned integer value type

FWIW: here is the link to the prototype https://github.com/apple/swift/blob/master/test/Prototypes/Integers.swift.gyb Max > On May 25, 2016, at 3:53 PM, Dave Abrahams via swift-evolution > wrote: > > > on Sat May 21 2016, Károly Lőrentey > wrote: > >> On 2

Re: [swift-evolution] [Pitch] Add `mapValues` method to Dictionary

on Tue May 24 2016, Nate Cook wrote: >> On May 24, 2016, at 7:43 AM, Matthew Johnson via swift-evolution >> wrote: >> >> Sent from my iPad >> >> On May 24, 2016, at 12:59 AM, Brent Royal-Gordon via swift-evolution >> wrote: > >> I have a small remark though, wouldn’t it be better to

Re: [swift-evolution] [PITCH] ADD AN @RESTRICTED DECLARATION ATTRIBUTE

> @available(OS X 10.9, restricted) Personally, I would prefer something like this, perhaps spelled: @available(OS X 10.9, only) When using shorthand form, you would have to write either `*` or `only` as the last element. `*` means "and any other platforms", while `only` means "only the

Re: [swift-evolution] [Deferred] SE-0090: Remove .self and freely allow type references in expressions

> On May 25, 2016, at 9:31 PM, Chris Lattner via swift-evolution > wrote: > > Proposal Link: > https://github.com/apple/swift-evolution/blob/master/proposals/0090-remove-dot-self.md > > The review of "SE-0090: Remove .self and freely allow type references in > expressions" ran from May 17…23

Re: [swift-evolution] [Proposal] Enums with static storedpropertiesforeach case

IMO (now I agree with Leonardo) all we need is allowing a tuple as raw type for enum and in this case compiler should allow as to skip '.rawValue.' and to use tuple values on enum instance directly like: enum Planets: (mass: Double, description: String) { case earth = (mass: 1.0, description:

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

> * Already very similar notation for enums where you leave off the entity name > when it can be implied. That's the problem. Leading dot already means something—it means "look up a static member of the type we're expecting here". (That's what you're actually doing when you access an "enum case

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] [Accepted with modifications] SE-0045: Add scan, prefix(while:), drop(while:), and unfold to the stdlib

on Fri May 06 2016, Kevin Ballard wrote: > On Fri, May 6, 2016, at 07:33 PM, Dave Abrahams via swift-evolution wrote: >> >> on Fri May 06 2016, Kevin Ballard wrote: >> >> > On Fri, May 6, 2016, at 06:05 PM, Dave Abrahams via swift-evolution wrote: >> >> > >> >> on Fri May 06 2016, Kevin Ball

Re: [swift-evolution] [Accepted with modifications] SE-0045: Add scan, prefix(while:), drop(while:), and unfold to the stdlib

on Fri May 06 2016, Kevin Ballard wrote: > As I said to Chris in an off-list email, unfold() was actually the > function that I was the most excited about in the proposal, because it > allows for a very elegant solution to a variety of looping needs, > especially now that we've gotten rid of the

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

(inline) On Thu, May 26, 2016 at 12:22 PM, David Hart wrote: > Hi Austin, > > I never had te occasion to say thanks for the work you have put in this > proposal, so thanks! I’m really looking forward to be able to have some > form of it accepted and implemented in Swift. > Thank you! I just hop

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

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 similarly; if a Go type implements all the requirements of an interface it conforms automatically.

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

IMO nice idea, but I see that this could be confused with using enum values: enum E { case one case two static func foo(e: E) {} } struct S { var one = 100 ... func f() { E.foo(.one) print(one) // ? print(.one) someFunc(.something) // is it enum

Re: [swift-evolution] [Proposal] Enums with static storedpropertiesforeach case

I personally don't like the Java values() solution. Nor the solution based on dictionary where you need to use ! to unwrap the optionals. There are IMHO only two ways to solve this: 1) allow enums with RawValue being object (AnyClass) and make allow case values to be computed. In the Planet cas

Re: [swift-evolution] [Proposal] Enums with staticstoredpropertiesforeach case

Ok, I'm not familiar with Scala but if the language does not have support for the type of enums we're discussing it may be their chosen mechanism to handle enums with associated values (feel free to correct me if I'm wrong always) but my main point for enums is still: do we really need to introd

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] [Proposal] Enums with static storedpropertiesforeach case

I get it and think this was really very interesting in Delphi and I wouldn't mind having something like this in Swift. But despite being able to extend associated information through the use of another array we'd still have more verbosity and scattering than with tuples to implement the examples

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

I alway enjoy hearing your ideas. In a good or funny way? I don’t want to say dumb things you know. :D 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 similarly; if a Go type implemen

Re: [swift-evolution] [Proposal] Enums with static storedpropertiesforeach case

Not really. When you take Scala's case classes, they are exactly for this purpose: http://docs.scala-lang.org/tutorials/tour/case-classes.html abstract class Term case class Var(name: String) extends Term case class Fun(arg: String, body: Term) extends Term case class App(f: Term, v: Term) exten

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

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 similarly; if a Go type implements all the requirements of an interface it conforms automatically. The

Re: [swift-evolution] [Proposal] Enums with static storedpropertiesforeach case

I think these are different concepts. Classes and structs are abstractions for something (think of them as empty forms while instances are filled forms) while enums identify a closed set of values (filled forms) known ahead of use. Sealed classes are intended to limit extensions to a class not t

[swift-evolution] [Accepted] SE-0093: Adding a public base property to slices

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0093-slice-base.md The review of "SE-0093: Adding a public base property to slices" ran from May 19…23, 2016. The proposal has been *accepted* without changes: - There was little feedback from the community other tha

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

Since this keeps coming up, it seems that something would be good here. Perhaps this has been explored before but why can’t we just use dot without the word “self", to indicate self? class DotIsSelf { func p() -> String { return "self p" } func g() { print(.p())

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

I’m inclined to say -1, for reasons that’ve already been mentioned, but can anyone elaborate on “a drastically different architecture to the type checker”? - Dave Sweeris > On May 25, 2016, at 4:43 PM, David Hart via swift-evolution > wrote: > > Here’s a pitch for removing associated type in

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

Hi Austin, I never had te occasion to say thanks for the work you have put in this proposal, so thanks! I’m really looking forward to be able to have some form of it accepted and implemented in Swift. Here are a few comments: 1) Why would Any<> and Any be illegal? What error messages would the

Re: [swift-evolution] [swift-users] Unsafe(Mutable)Pointer (suc)predecessor and advancedBy functions

This is where it gets tricky. When you create a chunk of memory using 'UnsafeMutablePointer.memory()' or 'alloc()', it's as if you are programming in C with 'malloc' and 'free'. The memory you create and the objects you put in that memory don't participate in ARC - the runtime will not track re

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

Sent from my iPad > On May 26, 2016, at 12:52 PM, Thorsten Seitz via swift-evolution > wrote: > > >> Am 26.05.2016 um 07:53 schrieb Austin Zheng via swift-evolution >> : >> >> The inimitable Joe Groff provided me with an outline as to how the design >> could be improved. I've taken the li

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

I’d like to throw one idea of mine in the room I couldn’t stop thinking when I read one of Thorsten’s replies on SE–0095 review thread. This wiki section explains the existential types where we have something like this: "T = ∃X { a: X; f: (X → int); } This could be implemented in different ways

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

On Thu, May 26, 2016 at 12:47 PM, L. Mihalkovic via swift-evolution < swift-evolution@swift.org> wrote: > > > On May 25, 2016, at 11:43 PM, David Hart via swift-evolution < > swift-evolution@swift.org> wrote: > > Here’s a pitch for removing associated type inference as per the Generics > Manifesto

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

on Wed May 25 2016, Tony Allevato wrote: > I was inspired to put together a draft proposal based on an older discussion > in > the Universal Equality, Hashability, and Comparability thread > that recently > got necromanced (thanks

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

> On May 26, 2016, at 12:37 AM, Leonardo Pessoa via swift-evolution > wrote: > > -1. I don't really see how this is a bad thing and why it has to change. To > me this is one of the best features of the language and I want more of it > (I've been through some situations it was totally obvious

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

I suppose "a.Element" could be considered a path-dependent type. My inclination is to disallow the use of "a.AssociatedType" if 'a' is a generic type like T inside func(a: T) or class, and only allow it if 'a' is an existential. This goes back to the notion that existential types and generic types

Re: [swift-evolution] [Proposal] Enums with static stored propertiesforeach case

Now thinking about this, what would solve this partially is being discussed in another topic here - sealed clasees. Each planet would have its own class and the superclass Planet would be abstract sealed. You would then be able to do an effective switch on the instance of the planet, which woul

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

Something like type<…> was considered at the very start of the whole discussion (in this thread), but it does not solve the meaning of an existential type and also might lead to even more confusion. >From my perspective I wouldn’t use parentheses here because it looks more like >an init without

Re: [swift-evolution] [Proposal] Enums with static stored propertiesforeach case

Yes, this was mentioned in a similar thread in this email list earlier. There is even some proposal for such .values() for Swift enums. But this values() in Java is not the same thing as discussed dictionary with *keys* of enum type or Delphi's arrays with *index* of enum type. Could you writ

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

A `deriving` keyword, at the very least, is pretty explicitly *not* an all-or-nothing situation. If you want to define equality/hashability for your type manually, don't use `deriving`. This should leave the simplest cases to auto generation and anything more complex should be handled by the develo

Re: [swift-evolution] [Proposal] Enums with static stored propertiesforeach case

Java enums automatically have a static values() method that return an array with all values in an enum. -Original Message- From: "Vladimir.S via swift-evolution" Sent: ‎26/‎05/‎2016 02:36 PM To: "Ross O'Brien" Cc: "swift-evolution" Subject: Re: [swift-evolution] [Proposal] Enums with

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

> Am 26.05.2016 um 07:53 schrieb Austin Zheng via swift-evolution > : > > 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 > to account for his advice. > > It turns out the runtime type sys

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

Don't think {} is better here, as they also have "established meaning in Swift today". How about just Type(P1 & P2 | P3) - as IMO we can think of such construction as "creation" of new type and `P1 & P2 | P3` could be treated as parameters to initializer. func f(t: Type(P1 & P2 | P3)) {..}

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

> On May 25, 2016, at 11:43 PM, David Hart via swift-evolution > wrote: > > Here’s a pitch for removing associated type inference as per the Generics > Manifesto. If we want to do it, we’d better do it before Swift 3: > > Remove associated type inference > Proposal: SE- > Author: David H

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] [swift-evolution-announce] [Review] SE-0089: Replace protocol syntax with Any

Inventing all these oneOf<> AllOf<> feel like an incomplete algebra that only exist because of a fixation on cramming everything inside the Any<> box. What are they? How will they be described in Swift programming manuals? Pseudo protocols? Protocols? Then what will their .Type be? I'm sorry,

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

On 26.05.2016 19:50, Ross O'Brien wrote: Perhaps there's an argument to be made for a sort of 'enumDictionary' type - a dictionary whose keys are all the cases of an enum, and is thus guaranteed to produce a value. In Delphi(Pascal) you can define an array with indexes of enum type i.e.: type

Re: [swift-evolution] [Pitch] Allow explicit specialization of generic functions

A perfectly reasonable preference. For me, "as" reads as a potential type conversion (which I don't want) and specifying the type on the local can be verbose in cases when a single input or output type is sufficient for disambiguation. plus1 has 1/3 the number of types specified in the type deducti

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

How about something like Type{P1 & P2 | P3} the point being that "<...>" has an established meaning in Swift today which is not what is expressed in the "" contained inside Any. > On May 26, 2016, at 7:11 PM, Dave Abrahams via swift-evolution > wrote: > > >> on Thu May 26 2016, Adrian Zubar

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

I get this sense that everyone is foxussing on the how, without having clearly defined the what. And this is not the first time I see a lot of great ideas flaring about how to convey a given syntax, without reading a proper definition of the concept. > On May 26, 2016, at 6:15 PM, Michael Pete

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

I’m not against Any<…> or something, I just wanted to throw this in the room because I’ve seen someone being confused about what Any<…> might mean. The generic manifesto has a nice wordplay that explains the true meaning: “Any type that conforms to … (all constraints) … .” But someone might sti

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

what i care about is to have a choice about what DEFINES the identity of my values, not just an all-or-nothing situation. > On May 26, 2016, at 5:18 PM, T.J. Usiyan via swift-evolution > wrote: > > +1 to a `deriving` keyword > >> On Thu, May 26, 2016 at 3:58 AM, Michael Peternell via swift-ev

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

on Thu May 26 2016, Adrian Zubarev wrote: > There is great feedback going on here. I'd like to consider a few things here: > > * What if we name the whole thing `Existential<>` to sort out all > confusion? Some of us believe that “existential” is way too theoretical a word to force into the off

Re: [swift-evolution] Add a stride(by:) method to ClosedRange

on Fri May 20 2016, Tim Vermeulen wrote: > * that there was no one obvious behavior with a negative stride size > (range > operators require a smaller number on the lhs and a bigger one on the rhs, > so you can't write `9...0`, but stride(from:to:by) can start from a bigger > nu

Re: [swift-evolution] [PITCH] ADD AN @RESTRICTED DECLARATION ATTRIBUTE

Do we then need @restricted? It could be done like this using @available: @available(only OS X 10.9, iOS 9.1, message="123") @available(restricted OS X 10.9) @available(OS X 10.9, restricted) It would make sense either to split all the availability annotations (deprecated, unavailable, ...), or

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

Perhaps there's an argument to be made for a sort of 'enumDictionary' type - a dictionary whose keys are all the cases of an enum, and is thus guaranteed to produce a value. I think the question I have is how you'd access the values, syntactically. To use the Planet example, if '.earth' is a value

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

On Thu, May 26, 2016, at 02:26 AM, David Hart via swift-evolution wrote: > I believe it also helps readability. Associated type are part of the > declaration and I think it's worth pursuing better readability than > programmer friendliness at the declaration. When reading a type > declaration that

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

> Am 26.05.2016 um 17:35 schrieb Matthew Johnson : > > >> 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. T

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

> On May 26, 2016, at 10:45 AM, Thorsten Seitz wrote: > >> >> Am 26.05.2016 um 17:29 schrieb Matthew Johnson > >: >> >>> >>> On May 26, 2016, at 10:13 AM, Thorsten Seitz >> > wrote: >>> Am 26.05.2016 um 16:59 schrieb Matth

Re: [swift-evolution] [Review] SE-0094: Add sequence(initial:next:) and sequence(state:next:) to the stdlib

On behalf of Dmitri Gribenko, Max Moiseev, and myself: on Thu May 19 2016, Kevin Ballard wrote: > After having given this some thought, it seems apparent that `sequence > (state:next:)` is equivalent to `AnyIterator({ ... })` where the closure > captures a single mutable variable. Yes.

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

Or(if we are sure we'll don't forget to udpate `infoDict` in case of new added case in future): enum Planet { case earth case moon struct PlanetInfo { var mass: Double var description: String } private static let infoDict = [ Planet.earth :

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

> Am 26.05.2016 um 17:29 schrieb Matthew Johnson : > >> >> On May 26, 2016, at 10:13 AM, Thorsten Seitz > > wrote: >> >>> >>> Am 26.05.2016 um 16:59 schrieb Matthew Johnson >> >: >>> On May 26, 2016, at 9:52 AM, Thorsten Se

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

> On May 26, 2016, at 10:36 AM, Austin Zheng wrote: > > Yes, that's definitely an oversight. > > That being said, the example is also actually incorrect, because AFAIK it's > not possible to conform a type T to multiple protocols A and B, and have > A.Element and B.Element be different types

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

> On May 26, 2016, at 10:27 AM, Austin Zheng wrote: > > >> On May 26, 2016, at 6:08 AM, Matthew Johnson > > wrote: >> >> >> >> Sent from my iPad >> >> On May 26, 2016, at 6:59 AM, Taras Zakharko via swift-evolution >> mailto:swift-evolution@swift.org>> wrote:

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

Yes, that's definitely an oversight. That being said, the example is also actually incorrect, because AFAIK it's not possible to conform a type T to multiple protocols A and B, and have A.Element and B.Element be different types (i.e. the constraint is redundant). So it should be rewritten as

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

> On May 26, 2016, at 6: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] Enhanced existential types proposal discussion

> On May 26, 2016, at 6:02 AM, Matthew Johnson wrote: > > I really like the enhancement. This makes a lot of sense. All members are > visible, but some members can't be called because you can't form an argument > of the necessary type (i.e. when it is a non-concrete associated type and you

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

> On May 26, 2016, at 6:08 AM, Matthew Johnson wrote: > > > > Sent from my iPad > > On May 26, 2016, at 6:59 AM, Taras Zakharko via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > >> This looks very nice! >> >> Two questions/comments >> >> 1. I would prefer to write simpler

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

> On May 26, 2016, at 10:13 AM, Thorsten Seitz wrote: > >> >> Am 26.05.2016 um 16:59 schrieb Matthew Johnson > >: >> >>> >>> On May 26, 2016, at 9:52 AM, Thorsten Seitz >> > wrote: >>> Am 26.05.2016 um 15:40 schrieb Matthe

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

+1 to a `deriving` keyword On Thu, May 26, 2016 at 3:58 AM, Michael Peternell via swift-evolution < swift-evolution@swift.org> wrote: > Can we just copy&paste the solution from Haskell instead of creating our > own? It's just better in every aspect. Deriving `Equatable` and `Hashable` > would bec

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

The problem is that PlanetInfo values are recreated each time while they are static. Imagine if PlanetInfo where some type that expensive to create performance wise. You could solve it by: enum Planet { struct PlanetInfo { var mass: Double var description: String } ca

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

> Am 26.05.2016 um 16:59 schrieb Matthew Johnson : > >> >> On May 26, 2016, at 9:52 AM, Thorsten Seitz > > wrote: >> >>> >>> Am 26.05.2016 um 15:40 schrieb Matthew Johnson >> >: >>> >>> >>> >>> Sent from my iPad >>> >>> On May 26,

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

Thank you for your comments! (inline) > On May 26, 2016, at 4:59 AM, Taras Zakharko wrote: > > This looks very nice! > > Two questions/comments > > 1. I would prefer to write simpler existential types without Any, e.g.: > > let a: Sequence where Sequence.Iterator.Element == Int > >

Re: [swift-evolution] [Pitch] Allow explicit specialization of generic functions

> On May 25, 2016, at 11:37 PM, David Hart wrote: > > The former. This proposal is simply to make certain scenarios which require > to be explicit to be more elegant and more in line with generic types. > > Moreover, what you suggest might be dangerous. Imagine this code: > > func foo() -> (T

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

In the "where clause" section, shouldn't this be allowed: let a : AnySetAlgebraType.Element> I am asking because the acceptable type equality constraint is stated as: Type equality constraint: X == ConcreteType Jan E. ___ swift-evolution mailing

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

  1   2   >