Re: [swift-evolution] Enums and Source Compatibility

Can you go into more detail about why the core team didn't like this? public enum HomeworkExcuse { case eatenByPet case thoughtItWasDueNextWeek default // NEW} To me this is very close to an ideal solution, it fixes ABI concerns, it has sensible defaults. If it was changed a little bit:

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

Thanks for taking the time to respond. I think my confusion started from a misinterpretation that each method you're exposing from python would need a new implementation of the protocol. I've worked out my mistake, and you helped clarified with: > The system I’ve sketched out does not incorporate

Re: [swift-evolution] Re-pitch: Deriving collections of enum cases

On Mon, Nov 6, 2017 at 6:54 PM, Jacob Bandes-Storch via swift-evolution < swift-evolution@swift.org> wrote: > Over a year ago, we discussed adding a magic "allValues"/"allCases" static > property on enums with a compiler-derived implementation. The original > proposal > PR

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

HI, this proposal looks really interesting! I have a few questions: *Clarity on the proposal's intent* *Nice cheap bridges, or lowering barriers to bridging?* I can see this providing a nice quick interface to Python from Swift, but I'm not sure if the exposed interface will be very Swifty (you

Re: [swift-evolution] pure functions

> As Andy says, the major problem is that public API (which you can't see the implementation of in general) would all need to be marked up properly. The use-case I'm most interested in is reducing programmer error, I'm personally not too concerned about optimisations achieved by "pure" at this

Re: [swift-evolution] Pitch: Automatically deriving Equatable/Hashable for more value types

Nice work Tony! Is this proposal up for PR on swift-evolution as well? On Tue, 16 May 2017 at 7:30 am, Tony Allevato wrote: > Just to update everyone on the thread—it took a little longer than I'd > hoped to get the kinks out, but I finally have the implementation up as

Re: [swift-evolution] Pitch: Automatically deriving Equatable/Hashable for more value types

I suspected that would be the case with the function, thanks for confirming Tony. I agree with Tony that it's not worth slowing down this proposal to get tuples in, although it would be nice if this proposal applied to all value types. Thanks for pursuing this proposal, I have no intention of

Re: [swift-evolution] Pitch: Automatically deriving Equatable/Hashable for more value types

Also, when implementing this proposal it's going to be necessary to combine multiple hashes together. It would be awesome if this was done in a reusable way. If it doesn't slow the proposal down it would be awesome if it also introduced a stdlib function: public func combine_hashes(_ elements:

Re: [swift-evolution] Pitch: Automatically deriving Equatable/Hashable for more value types

You state that you will not synthesise conformance for tuples, I agree with this, but if a struct or enum holds a tuple it would be nice if it could be hashed if its members are all hashable. struct A { var a: Int, b: Int, c: Int } struct B { var tuple: (a: Int, b: Int, c: Int) } I'd

Re: [swift-evolution] Pitch: Automatically deriving Equatable/Hashable for more value types

o syntax; effectively, as though there exists an "extension > Equatable where [ all members : Equatable ]" with a default implementation. > > > On Thu, May 4, 2017 at 17:13 John McCall <rjmcc...@apple.com> wrote: > >> On May 4, 2017, at 6:10 PM, Andrew Bennett

Re: [swift-evolution] Pitch: Automatically deriving Equatable/Hashable for more value types

I agree, let's make it opt-in. This looks really great, I'm excited to get generated conformance for Equatable/Hashable in time for Swift 4. I think it's worth mentioning that Encoding/Decoding generated conformance is already accepted and implemented in Swift 4. The implementation and

Re: [swift-evolution] RFC: Preventing Retain Cycles (Memory Ownership Model)

for users accidentally taking strong references. On Sat, Jul 30, 2016 at 2:21 PM, Chris Lattner <clatt...@apple.com> wrote: > On Jul 29, 2016, at 6:42 PM, Andrew Bennett via swift-evolution < > swift-evolution@swift.org> wrote: > > I wrote this a few months ago, but we we

Re: [swift-evolution] RFC: Preventing Retain Cycles (Memory Ownership Model)

oo protocol > > > Also, how do you encode that your example's "addCallback" closure > parameter can't have a strong reference to `self`? > You encode it by not including it in the list of owned types. If you want to be able to have a strong reference to self you'd need `@

Re: [swift-evolution] RFC: Preventing Retain Cycles (Memory Ownership Model)

s > development, when it was attempting to provide language-supported shared > references without GC, and it didn't work out well for them in practice. > > -Joe > > > On Jul 29, 2016, at 6:42 PM, Andrew Bennett via swift-evolution < > swift-evolution@swift.org> wr

[swift-evolution] RFC: Preventing Retain Cycles (Memory Ownership Model)

I'd like an *opt-in* way to verify and prevent *unintentional strong references* in Swift. This can be used to verify ownership structures, and ultimately avoid retain cycles. Read a draft proposal here:

[swift-evolution] Allowing enum extensions to also be able to expand case options

<austinzh...@gmail.com <javascript:_e(%7B%7D,'cvml','austinzh...@gmail.com');>> wrote: > Unions are a no-go. > > https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md > > > On Jun 30, 2016, at 5:00 PM, Andrew Bennett via swift-evolution < >

Re: [swift-evolution] Allowing enum extensions to also be able to expand case options

gt; > On Jun 30, 2016, at 5:00 PM, Andrew Bennett via swift-evolution < > swift-evolution@swift.org > <javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>> wrote: > > How many of these use cases would be safely addressed if two Enum types > could be unioned

Re: [swift-evolution] Allowing enum extensions to also be able to expand case options

How many of these use cases would be safely addressed if two Enum types could be unioned to form a new type? It could use syntax similar to what is being proposed for existentials: (A|B), or something like this: enum C: A, B {} Swift could generate code like this: enum A { case A1, A2 } enum

Re: [swift-evolution] [Pitch] Remove destructive consumption from Sequence

I agree that there should be a type for a non-destructive re-entrant sequence. IIRC in past discussions one of the counter arguments given was IO stream sequences. It is likely undesirable to buffer the entire stream, but without buffering there's no guarantee of getting the same values. These

[swift-evolution] [Discussion] Default Closure Arguments

I'd like to be able to do this: func callSomething(callback: (test: (arg: Int = 4) -> Void) -> Void) { callback(test: { print($0) }) } callSomething { test in test() } Ideally the default argument would be part of the closure's type signature. If-not then it could be part of

Re: [swift-evolution] [Pitch] "unavailable" members shouldn't need an impl

Unavailable doesn't mean un-callable. - If you're marking an override or required initialiser as unavailable, it's still possible it's called dynamically, or by super. - If you're marking it unavailable for some OS versions, it could still be called by the other OS versions. - If

Re: [swift-evolution] Pitch: @required attribute for closures

Responses inline On Mon, Jun 6, 2016 at 12:23 PM, Matthew Johnson wrote: > > > Sent from my iPad > > On Jun 5, 2016, at 8:43 PM, Andrew Bennett wrote: > > Thanks Matthew, my responses are inline: > > On Mon, Jun 6, 2016 at 10:32 AM, Matthew Johnson

Re: [swift-evolution] Pitch: @required attribute for closures

Thanks Matthew, my responses are inline: On Mon, Jun 6, 2016 at 10:32 AM, Matthew Johnson wrote: > > > Sent from my iPad > > On Jun 5, 2016, at 6:50 PM, Andrew Bennett wrote: > > Perhaps I was unclear, in my explanation. The guarantee I'm enforcing is

Re: [swift-evolution] Pitch: @required attribute for closures

Perhaps I was unclear, in my explanation. The guarantee I'm enforcing is that the closure is called exactly once before being released. Everything I suggested is a compile-time check. The compile-time warning and runtime `fatalError` I suggested could be replaced with a compile-time error,

Re: [swift-evolution] Pitch: @required attribute for closures

"runtime circumstance" -> "runtime assertion", weird typo. On Sun, Jun 5, 2016 at 9:56 PM, Andrew Bennett wrote: > I like this. > > One of the suggestions on @noescape(once) was that it just becomes @once > and works with escaping closures too. It might be possible if compile

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

I imagine you can use a combination of: *Deferred for Future Discussion*: https://github.com/apple/swift-evolution#deferred-for-future-discussion *Accepted proposals which do not have a complete implementation:*

Re: [swift-evolution] [Review] SE-0073: Marking closures as executing exactly once

* What is your evaluation of the proposal? +1 I agree with others that there are opportunities to generalise this proposal. It would be pretty magical if it could be applied to escaping closures, less magical if that's just adding a runtime assertion. It would also be much more flexible if it

Re: [swift-evolution] [Review] SE-0073: Marking closures as executing exactly once

Replies inline: On Sat, May 7, 2016 at 12:37 PM, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > on Fri May 06 2016, Andrew Bennett wrote: > > > Hi Dave, > > > > Sorry, Dave, sending a second time as I forgot to Reply-All. > > > > I agree,

Re: [swift-evolution] [Review] SE-0073: Marking closures as executing exactly once

Hi Dave, Sorry, Dave, sending a second time as I forgot to Reply-All. I agree, this proposal doesn't allow multiple closures where only one of them should be run, and it should only be run once. I personally don't think lacking that functionality is worth blocking this proposal for, another

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

Thanks for clarifying, my responses are inline. On Fri, Apr 29, 2016 at 10:51 AM, Erica Sadun wrote: > > On Apr 28, 2016, at 6:44 PM, Andrew Bennett wrote: > > Hey, what annotations would I have in this case: > > Module 1: > > Type AType { func foo() {

Re: [swift-evolution] [Review] SE-0070: Make Optional Requirements Objective-C only

, Charles Srstka <cocoa...@charlessoft.com> wrote: > On Apr 27, 2016, at 9:30 AM, Andrew Bennett via swift-evolution < > swift-evolution@swift.org > <javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>> wrote: > > > Sorry if this has been discuss

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

Sorry, I sent too early. Example should have been: struct Example: A { func get() -> T {...} } My mistake does bring up another question. What if it only conforms after the method is defined, in another module? extension Example: A {} On Thursday, 28 April 2016, Andrew Bennett

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

Great proposal, I think it will clear up some mistakes. What happens when it is only an override sometimes? For example: protocol A { associatedtype Element func get() -> Element } extension A where Element: ArrayLiteralConvertible { func get() -> Element { return [] } } struct

Re: [swift-evolution] [Review] SE-0070: Make Optional Requirements Objective-C only

Sorry if this has been discussed, but have you considered dropping optional entirely, making it throw, and a default implementation that throws a selector not found exception? This is approximately what you would expect using it in objc. I don't think it has the complexity discussed in the

Re: [swift-evolution] SE-0066 Reaction

I initially had similar concerns to Mishal, but I worked my way through it and found I was wrong. In current Swift you can have a function: A -> B -> C Adding brackets for clarity, that is equivalent to this (current Swift): A -> (B -> C) After this proposal this will become: (A) -> ((B) -> C)

Re: [swift-evolution] Guaranteed closure execution

I agree, it would be good if someone like Brent or Chris could chip in. However, I think that @noescape(once) is still fine. As long as a @noescape(once) closure must either be passed to a single function, or called once it seems enforceable. I don't believe a @noescape closure can be stored, so

Re: [swift-evolution] [Idea] Replace enumerate() with something more explicit

,Self> { return zip(self.indices, self) } On Sat, Apr 16, 2016 at 11:12 AM, Charles Srstka <cocoa...@charlessoft.com> wrote: > On Apr 15, 2016, at 8:09 PM, Andrew Bennett via swift-evolution < > swift-evolution@swift.org> wrote: > > > I'm in support of a method of getting

Re: [swift-evolution] Open Source version of "The Swift Programming Language"

I think this is a great idea. I'm not sure how big a task it is to open source the current system. Hopefully it's easy for Apple to extract the content, convert it to markdown (if needed), and allow it to be updated from a git repo. It would be great if the website allowed you to browse tagged

Re: [swift-evolution] [Idea] Replace enumerate() with something more explicit

I'm in support of a method of getting a sequence of (Index,Value) pairs (as you know from the other thread). I think I'm leaning toward option three if it's equivalent to `zip(self.indices, self)`, ideally as a concise property like keys/values on a Dictionary. I've been using zip in production.

Re: [swift-evolution] [Proposal] mapValues

Thanks Brent for your in-depth response - I've responded in another thread so we don't pollute this one (sorry Jonathan): http://thread.gmane.org/gmane.comp.lang.swift.evolution/14665 I think mapValues is great, and really needed in Swift. I'm a definite +1 on a version of map that only maps the

[swift-evolution] [Discussion] Dictionary Key as Index

I've moved this discussion over from "[swift-evolution] [Proposal] mapValues" which discusses mapValues, like map but it preserves keys and transforms values, returning a Dictionary. I'm in favour mapValues, but I feel like it should be the default behaviour of map for a Dictionary. Being the

Re: [swift-evolution] [Proposal] mapValues

This is a clarification on what I meant (I haven't had much time to test it, but I think it's representative): https://gist.github.com/therealbnut/c223d90a34bb14448b65fc6cc0ec70ac Sorry if I've derailed this conversation, I'm in support of mapValues, but I feel like map itself should be mapping

Re: [swift-evolution] [Proposal] mapValues

I don't think I've ever called map on a dictionary in production code, only a mapValue function like this thread discusses. When do we actually want to call map on a dictionary? I feel like mapValue should be the default. I'm wondering if `Dictionary.Element`should be `Value`, instead

Re: [swift-evolution] Guaranteed closure execution

Hi, not beyond this thread that I have seen. I think it's worth you summarizing this thread in a formal proposal and putting it up for discussion or submitting it as a PR :) On Sunday, 10 April 2016, Gwendal Roué wrote: > Hello all, > > I was wondering if this topic

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

I agree, separate protocols is preferable. I think it needs some more thought though, some UIKit protocols have several optional methods, I'm not sure if a protocol for each would be very clean. The other thing that needs consideration is whether it's possible to automatically convert objc with

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

For a while I've thought it would be useful to have a way to refer to the protocol's default implementation, even when you provide your own. We could possibly do away with most people's concerns and optional methods if we could do something like this: if MyProtocol.someMethod === Self.someMethod

Re: [swift-evolution] Revisiting 0004 etc. - Swift deprecations

On that note here is a convenient pattern I've used in the rare cases I haven't been able to convert to a "for in" syntax when refactoring: var i = 0 while i < 10 { defer { i += 1 } print(i) } To be honest I don't really mind this syntax, I often found during refactoring: * the

Re: [swift-evolution] Update the signature of ObjectiveC.autoreleasepool [SR-842]

I like this proposal, but I think I agree with Chris, the return value seems inconsistent. I am +1 on rethrows. Your proposed autoreleasepool returns a (non discardable) value and/or performs a side-effect, depending on how it is being used. Also, most other standard library functions taking

Re: [swift-evolution] allowing to specify optionality with type inference

Hi Huges, You can achieve a very similar result like this: let x = 123 let y: Optional = x The generic arguments can be inferred in more complicated cases too, for example: let z: Set = [1, 2, 3] Which creates a Set rather than an Array. I hope this helps! Andrew Bennett On Thu, Mar

Re: [swift-evolution] [Pitch] Change the endIndex value for closed Ranges and Collections

Hi Pedro, I'm going to refer to what you're proposing as *lastIndex* to distinguish it from the current endIndex. Worth considering is indexes for things like a linked list (or other ForwardIndexType collections): - You can represent the endIndex in O(1) by using a nullable internally. -

Re: [swift-evolution] [proposal] Generic type aliases

Big +1 on this proposal from me. Does this proposal allow a protocol can have generic associated types? - associatedtype Something - associatedtype Something It's not mentioned, but I think it would be necessary at some point for completeness. On Thu, Mar 17, 2016 at 2:32 PM, Joe Groff

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0043 Declare variables in 'case' labels with multiple patterns

Excellent point Brent. I was considering that this would have to be an exact match, I hadn't considered the need for an (x: Y) syntax. This probably should be considered in a future proposal though. The future proposal may make sense to be after existential types are explored, so that common

Re: [swift-evolution] [Review] SE-0047 Defaulting non-Void functions so they warn on unused results

*What is your evaluation of the proposal?* +1 *Is the problem being addressed significant enough to warrant a change to Swift?* Yes, the current annotation is present on most non-void functions, it adds a large number of lines to files that are properly annotated. *Does this proposal fit well

Re: [swift-evolution] [Mini-proposal] Require @nonobjc on members of @objc protocol extensions

I'm on the fence here, I think it's a good solution if a project has ongoing objc dependencies. However I have a few issues/suggestions: 1) If a project is iteratively migrating from objc to swift, as I'm sure many are (a large project I'm working on included), then it would make that job much

Re: [swift-evolution] sortBy, minElementBy and maxElementBy methods

As an alternative to minElement and maxElement, this could reduce the number of overloads and provide autocomplete: extension SequenceType { @warn_unused_result func reduce( @noescape combine: (C, C) throws -> Bool, @noescape by key: Generator.Element -> C )

Re: [swift-evolution] Proposal: Add SequenceType.first

Related to this I've been toying around with a tweak to GeneratorType - it could clear up some of the issues with .first consuming part of the sequence: public protocol NewGeneratorType { typealias Element func next() -> (value: Element, state: Self)? } extension NewGeneratorType {

Re: [swift-evolution] Proposal: CollectionType.cycle property for an infinite sequence

Hi Kevin, The issue I was seeing was because AnySequence uses the protocol extension on SequenceType for its implementations of filter/suffix/prefix etc. So I don't think it's taking into account any implementations of those on the base sequence's type. The problem basically comes down to this:

Re: [swift-evolution] Proposal: Add function SequenceType.find()

+1 we also have a very similar extension. On Wed, Dec 30, 2015 at 1:40 PM, Keith Smiley via swift-evolution < swift-evolution@swift.org> wrote: > +1. We've added an extension for this and find it very useful. > On Tue, Dec 29, 2015 at 18:38 Kevin Ballard via swift-evolution < >

Re: [swift-evolution] Proposal: Rewrite Swift compiler in swift to get ideas for further language evolution.

This may address many of the concerns, and perhaps lower the barriers to the community contributing: How about instead of rewriting the entire compiler in Swift, we just rewrite the Swift -> SIL component? On Mon, Dec 21, 2015 at 10:54 PM, Jean-Daniel Dupas via swift-evolution <

Re: [swift-evolution] Coroutine for Swift

Great proposal! I'm all for this, I think your proposed implementation is pretty good too. It would be interesting to expand the proposal to consider more cases in more detail: * Concurrency * SequenceType versus GeneratorType * Should a language feature depend on the Standard Library

Re: [swift-evolution] [Proposal] function "return" optional keyword.

+1 for consistency with closures On Sun, Dec 20, 2015 at 8:15 AM, Stephen Christopher via swift-evolution < swift-evolution@swift.org> wrote: > The discussion I was remembering, comment courtesy of Chris: > https://devforums.apple.com/message/1014317#1014317 > > (linked from

Re: [swift-evolution] Brace syntax

-1 I agree with Charles, although Chris and Kevin made some pretty good points too :) On Sun, Dec 20, 2015 at 3:03 PM, Charles Srstka via swift-evolution < swift-evolution@swift.org> wrote: > On Dec 19, 2015, at 7:39 PM, Alexander Regueiro via swift-evolution < > swift-evolution@swift.org>

Re: [swift-evolution] [Proposal] function "return" optional keyword.

Great points Kevin, that's pretty much my thinking as well. If we're heading towards everything being an expression then it'll happen, perhaps that change shouldn't be incremental as you've suggested, I'm not sure. The only time I've found I've naturally wanted to do this is with things like

Re: [swift-evolution] Shift operator: the type of the second operand

+1 Something worth considering with this proposal: Should it be IntMax rather than Int? (or UIntMax, does a negative count make sense?). Although it's probably never going to be enough if you want to calculate the next largest known prime number in swift, the last was 2^57885161 − 1. *Also if