Re: [swift-evolution] [Review] SE-0078: Implement a rotate algorithm, equivalent to std::rotate() in C++

> On May 3, 2016, at 11:51 PM, Xiaodi Wu via swift-evolution > wrote: > >> * What is your evaluation of the proposal? > > +1. A very useful function to have on collections. > > In FORTRAN and in languages that take inspiration from it, the same function >

Re: [swift-evolution] #if os(Windows) and MSVC/Cygwin Compatibility

Dear Joe, Chris, Swift Community, Here is my quick fire view. What about adding a builtin directive called environ(...) for holding OS-specific environmental differences. So in the case of Windows, we would potentially have environ(msvc), environ(cygwin), environ(mingw), environ(nano) etc. Thus,

Re: [swift-evolution] #if os(Windows) and MSVC/Cygwin Compatibility

> On May 3, 2016, at 9:43 PM, Joe Groff wrote: > > >> On May 3, 2016, at 9:40 PM, Chris Lattner wrote: >> >> >>> On May 3, 2016, at 9:39 PM, Joe Groff wrote: >>> >>> On May 3, 2016, at 9:27 PM, Chris Lattner via swift-evolution

Re: [swift-evolution] [Proposal] Tuple Extensions

> On May 3, 2016, at 9:50 PM, Austin Zheng via swift-evolution > wrote: > > +1 to the interaction between variadic generics and extension of tuple types. > But this is a proposal I hope to see accepted and implemented at some point. > > Is there an official

Re: [swift-evolution] [Proposal] Tuple Extensions

Once-and-for-all implementations come in many flavors. For now, we have clear interest in making a limited subset of possible tuples properly Comparable. This will also make it easier to implement extensions to specific arities now and serve as a base for variadic generics if that is the path

Re: [swift-evolution] [Proposal] Tuple Extensions

> On May 3, 2016, at 9:52 PM, Robert Widmann wrote: > > Trouble is that I don't want variadic generics without corresponding support > from the type system which is untenable without HKTs (see last paragraph of > proposal). C++'s variadic implementation of

Re: [swift-evolution] [Proposal] Tuple Extensions

Trouble is that I don't want variadic generics without corresponding support from the type system which is untenable without HKTs (see last paragraph of proposal). C++'s variadic implementation of std::tuple is not elegant to my mind, and would have no place in a library I could think of

Re: [swift-evolution] [Review] SE-0078: Implement a rotate algorithm, equivalent to std::rotate() in C++

> * What is your evaluation of the proposal? > +1. A very useful function to have on collections. In FORTRAN and in languages that take inspiration from it, the same function is called a "circular shift"--IMO, it's a clearer name both by its associations with other uses of the term

Re: [swift-evolution] [Proposal] Tuple Extensions

> On May 3, 2016, at 9:13 PM, Developer via swift-evolution > wrote: > > I’ve been contemplating this idea for a while now, mostly because I think > it’s a very important feature, but also because I can’t find a single example > of a programming language getting it

Re: [swift-evolution] #if os(Windows) and MSVC/Cygwin Compatibility

> On May 3, 2016, at 9:40 PM, Chris Lattner wrote: > > >> On May 3, 2016, at 9:39 PM, Joe Groff wrote: >> >> >>> On May 3, 2016, at 9:27 PM, Chris Lattner via swift-evolution >>> wrote: >>> >>> MSVC and MinGW (again, AFAIK)

Re: [swift-evolution] #if os(Windows) and MSVC/Cygwin Compatibility

> On May 3, 2016, at 9:39 PM, Joe Groff wrote: > > >> On May 3, 2016, at 9:27 PM, Chris Lattner via swift-evolution >> wrote: >> >> MSVC and MinGW (again, AFAIK) use the same C ABI, and thus could be treated >> as the same target. >> > Part of

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0076: Add overrides taking an UnsafePointer source to non-destructive copying methods on UnsafeMutablePointer

> On May 3, 2016, at 8:56 PM, Chris Lattner wrote: > > Hello Swift community, > > The review of "SE-0076: Add overrides taking an UnsafePointer source to > non-destructive copying methods on UnsafeMutablePointer" begins now and runs > through May 9. The proposal is

Re: [swift-evolution] [Review] SE-0080: Failable Numeric Conversion Initializers

> The review of "SE-0080: Failable Numeric Conversion Initializers" begins now > and runs through May 9. The proposal is available here: > > > https://github.com/apple/swift-evolution/blob/master/proposals/0080-failable-numeric-initializers.md Hello, I'm all for it, but I'd like a

Re: [swift-evolution] [Review] SE-0074: Implementation of Binary Search functions

* What is your evaluation of the proposal? +1 * Is the problem being addressed significant enough to warrant a change to Swift? Yes * Does this proposal fit well with the feel and direction of Swift? Yes * If you have used other languages or libraries with a similar

Re: [swift-evolution] [Review] SE-0080: Failable Numeric Conversion Initializers

On May 3, 2016, at 9:19 PM, Charles Srstka wrote: > Is the proposal to add these initializers to protocols like IntegerType, or > just to individually add them to each of the numeric types? It’s unclear from > the proposal, but in case that question hasn’t been decided

Re: [swift-evolution] [Review] SE-0074: Implementation of Binary Search functions

> * What is your evaluation of the proposal? > +1. These are self-evidently useful functions. One issue: not sure I understand why the "customization points" are necessary as part of this particular proposal. If it's to support "future sorted collections," then the best motivating use

Re: [swift-evolution] #if os(Windows) and MSVC/Cygwin Compatibility

On May 3, 2016, at 11:43 AM, Jordan Rose via swift-evolution wrote: > We’ve had this kind of thing come up before, too, with the > Linux/FreeBSD/Android group vs. the OSX/iOS/watchOS/tvOS group, or with > 32-bit architectures vs. 64-bit architectures. Erica Sadun

Re: [swift-evolution] [Review] SE-0080: Failable Numeric Conversion Initializers

Is the proposal to add these initializers to protocols like IntegerType, or just to individually add them to each of the numeric types? It’s unclear from the proposal, but in case that question hasn’t been decided yet, I’d like to vote for putting them in the protocols. It’s bugged me for a

[swift-evolution] [Proposal] Tuple Extensions

I’ve been contemplating this idea for a while now, mostly because I think it’s a very important feature, but also because I can’t find a single example of a programming language getting it completely right. In Swift, the motif of tuples throughout the language would lead one to think that they

Re: [swift-evolution] [Review] SE-0060: Enforcing order of defaulted parameters

Count me among those who had no idea this feature even existed. The thing about the current behavior that strikes me as odd is that it only applies to parameters with default values. So foo(a: Int = 1, b: Int = 2) is reorderable, whereas foo(a: Int, b: Int) is not. This seems fairly

[swift-evolution] [Review] SE-0080: Failable Numeric Conversion Initializers

Hello Swift community, The review of "SE-0080: Failable Numeric Conversion Initializers" begins now and runs through May 9. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0080-failable-numeric-initializers.md Reviews are an important

[swift-evolution] [Review] SE-0076: Add overrides taking an UnsafePointer source to non-destructive copying methods on UnsafeMutablePointer

Hello Swift community, The review of "SE-0076: Add overrides taking an UnsafePointer source to non-destructive copying methods on UnsafeMutablePointer" begins now and runs through May 9. The proposal is available here:

[swift-evolution] [Review] SE-0074: Implementation of Binary Search functions

Hello Swift community, The review of "SE-0074: Implementation of Binary Search functions" begins now and runs through May 9. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0074-binary-search.md Reviews are an important part of the Swift

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

Hello Swift community, The review of "SE-0073: Marking closures as executing exactly once" begins now and runs through May 9. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0073-noescape-once.md Reviews are an important part of the Swift

[swift-evolution] [Review] SE-0060: Enforcing order of defaulted parameters

Hello Swift community, The review of "SE-0060: Enforcing order of defaulted parameters" begins now and runs through May 9. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0060-defaulted-parameter-order.md Reviews are an important part of

Re: [swift-evolution] Introduce OrderedSet type

I believe this would fall in line with by Proposal SE-0069: Mutability and Foundation Value Types: https://github.com/apple/swift-evolution/blob/master/proposals/0069-swift-mutability-for-foundation.md I notice there is no OrderedSet in this proposal. I find it odd that it doesn’t yet include

[swift-evolution] Introduce OrderedSet type

Hello Swift Community, Recently I have noticed that there is a Set type but no OrderedSet type yet. If I want a set that preserves the original order I have to go with NSOrderedSet but I think it would be nice to have a native implementation in the standard library. What are your thoughts on

Re: [swift-evolution] [Oversight] Reference types allow mutating methods through generics

Dave and I have pondered this before, and considered that one possible (drastic) solution is to ban classes from implementing protocols with mutating members, on the grounds that it’s very hard to write an algorithm that’s correct for both. func removing(_ element: Element) -> Self { var

Re: [swift-evolution] [Pitch] Reference storage for enum associated values

Why not separate the reference and its info? That way you can make the reference weak. enum ParentChildRelationship { case Son case Daughter } class Parent { lazy var son: Child = Child(sonOf: self) lazy var daughter: Child = Child(daughterOf: self) deinit { print("deinit

Re: [swift-evolution] [Pitch] Reducing the bridging magic in dynamic casts

Thanks everyone for the initial round of feedback. I've submitted a draft proposal: https://github.com/apple/swift-evolution/pull/289 https://github.com/jckarter/swift-evolution/blob/remove-bridging-conversion-dynamic-casts/proposals/-remove-bridging-from-dynamic-casts.md -Joe

Re: [swift-evolution] multi-line string literals.

inline Regards (From mobile) On May 2, 2016, at 2:23 PM, John Holdsworth > wrote: > >> I'm having trouble getting the `e` modifier to work as advertised, at least >> for the sequence `\\`. For example, `print(e"")` prints two

Re: [swift-evolution] [Pitch] Reference storage for enum associated values

It’s an interesting idea, but with the workaround you’ve found I wonder if it might make more sense to just have Unowned and Weak in the standard library? I’ve already defined these myself to work with a few awkward cases and to allow entries in collections to be weakly referenced. I mean it’d

Re: [swift-evolution] [Proposal] More Powerful Constraints for Associated Types

I know why: copy and paste :) Fixed btw. > On 03 May 2016, at 20:25, Dave Abrahams via swift-evolution > wrote: > > > on Mon May 02 2016, David Hart wrote: > >> Hi Doug, >> >> In the latest version of the proposal, which is now linked

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

An AnyValue protocol seems long overdue. I'm not sure how useful AnyEnum would be, though I support the idea since it could become useful in the future. Begin Message Group: gmane.comp.lang.swift.evolution MsgID:

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

Agreed, AnyObject seems like all we need to limit protocols to reference types. Begin Message Group: gmane.comp.lang.swift.evolution MsgID: on Mon May 02 2016, David Sweeris wrote: > I was just thinking

[swift-evolution] [Pitch] Reference storage for enum associated values

I would like to see something like this; it would not only eliminate extra code, but could potentially be more efficient. What syntax do you propose? If enum values were always labelled, I would expect something like SonOf(weak parent: Parent), but there would probably be resistance to

Re: [swift-evolution] #if os(Windows) and MSVC/Cygwin Compatibility

> On May 3, 2016, at 12:29 PM, John McCall wrote: > >> On May 3, 2016, at 12:15 PM, Joe Groff via swift-evolution >> wrote: >>> On May 3, 2016, at 11:43 AM, Jordan Rose via swift-evolution >>> wrote: >>> >>> We’ve

Re: [swift-evolution] multi-line string literals.

on Sat Apr 30 2016, David Waite wrote: > In my opinion, one problem is that we don’t have a reference to a > laundry or wish list of what features we would like around string > literals in the language. Without evaluating a proposal against all of > those features

Re: [swift-evolution] #if os(Windows) and MSVC/Cygwin Compatibility

> On May 3, 2016, at 12:15 PM, Joe Groff via swift-evolution > wrote: > >> On May 3, 2016, at 11:43 AM, Jordan Rose via swift-evolution >> wrote: ... >> >> One thing that I’d like to keep is that os(…) (like arch(…)) is (a) >>

Re: [swift-evolution] #if os(Windows) and MSVC/Cygwin Compatibility

> On May 3, 2016, at 12:15 PM, Joe Groff via swift-evolution > wrote: >> On May 3, 2016, at 11:43 AM, Jordan Rose via swift-evolution >> wrote: >> >> We’ve had this kind of thing come up before, too, with the >> Linux/FreeBSD/Android

Re: [swift-evolution] #if os(Windows) and MSVC/Cygwin Compatibility

> On May 3, 2016, at 11:43 AM, Jordan Rose via swift-evolution > wrote: > > We’ve had this kind of thing come up before, too, with the > Linux/FreeBSD/Android group vs. the OSX/iOS/watchOS/tvOS group, or with > 32-bit architectures vs. 64-bit architectures. Erica

Re: [swift-evolution] [Pitch] Reducing the bridging magic in dynamic casts

Here’s another argument in favor of the pitch: Take an array: let array = ["Foo", "Bar”] We can convert this to an NSArray via the bridge: let nsArray = array as NSArray We can also convert this to a CFArray: let cfArray = array as CFArray Now, let’s convert them back. let nsUntypedArray =

Re: [swift-evolution] #if os(Windows) and MSVC/Cygwin Compatibility

We’ve had this kind of thing come up before, too, with the Linux/FreeBSD/Android group vs. the OSX/iOS/watchOS/tvOS group, or with 32-bit architectures vs. 64-bit architectures. Erica Sadun wrote up quite a few of the choices here: http://thread.gmane.org/gmane.comp.lang.swift.evolution/12161/

Re: [swift-evolution] [Proposal] Improving operator requirements in protocols

Hi Dmitri, thanks for the great feedback. I've updated the pull request < https://github.com/apple/swift-evolution/pull/283>. On Mon, May 2, 2016 at 5:53 PM Dmitri Gribenko wrote: > On Mon, May 2, 2016 at 9:44 AM, Tony Allevato via swift-evolution >

Re: [swift-evolution] [Proposal] Improving operator requirements in protocols

On Tue, May 3, 2016 at 10:44 AM Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > on Mon May 02 2016, Chris Lattner wrote: > > > On May 2, 2016, at 4:59 PM, Xiaodi Wu wrote: > > > > Hmm, a thought going in a slightly different direction: if

Re: [swift-evolution] [Review] SE-0052: Change IteratorType post-nil guarantee

> > However, if there really is a 25% speedup on UTF-8 decoding for ASCII > input, that's a pretty significant point in favor of the change. I saw the > gist that was used to come up with this 25% number. But I do have to ask, > does the 25% increase still hold when talking about String.UTF8View,

Re: [swift-evolution] [Proposal] More Powerful Constraints for Associated Types

on Mon May 02 2016, David Hart wrote: > Hi Doug, > > In the latest version of the proposal, which is now linked to a pull request, > I > mentioned in the Detail Design section that the following syntax be > valid: Total nitpick, but I just can't hold it in: I don't

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

on Mon May 02 2016, David Sweeris wrote: > I was just thinking that: > > protocol Foo : reference {} > > might be more to the point than: > > protocol Foo : class {} > > I know that it’s currently a moot point because classes are the only* >

Re: [swift-evolution] proposal for a even simpler guard.. => guard!

on Mon May 02 2016, Austin Zheng wrote: > +1. The force unwrap operator is basically a runtime assert that enforces the > invariant that "this value should not be nil at this point of use, and if it > is > nil the programmer made a mistake". It is a perfectly

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

I’d love to see Swift go in this direction with protocols:                    +---+                    |  Any  |                    +---+---+                        |          +-+-+          |                           |   +--+---+             +-++   |

Re: [swift-evolution] [Proposal] Improving operator requirements in protocols

on Mon May 02 2016, Chris Lattner wrote: > On May 2, 2016, at 4:59 PM, Xiaodi Wu wrote: > > Hmm, a thought going in a slightly different direction: if these static > functions were called like any other function, there might not be a need > for > having

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

Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0070-optional-requirements.md Hello Swift Community, The review of SE-0070: "Make Optional Requirements Objective-C-only” ran from April 25 ... May 2, 2016. The proposal is *accepted* for Swift 3. The feedback on

[swift-evolution] [Accepted] SE-0061: Add Generic Result and Error Handling to autoreleasepool()

Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0061-autoreleasepool-signature.md Hello Swift Community, The review of SE-0061: "Add Generic Result and Error Handling to autoreleasepool()” ran from April 22 … 26, 2016. The proposal is *accepted* for Swift 3. The

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

+1 Yes please, get rid of the `class` keyword from protocols already and replace it with better implicit protocols. I posted the idea two weeks ago, but no one answered to it: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160418/015568.html Replacing `class` with

Re: [swift-evolution] #if os(Windows) and MSVC/Cygwin Compatibility

> On May 3, 2016, at 9:22 AM, Michael Buckley via swift-evolution > wrote: > I may be fundamentally misunderstanding the Windows Subsystem for Linux, but > I believe it just provides binary compatibility for Linux x86_64 command-line > tools, but doesn't quite

Re: [swift-evolution] #if os(Windows) and MSVC/Cygwin Compatibility

I may be fundamentally misunderstanding the Windows Subsystem for Linux, but I believe it just provides binary compatibility for Linux x86_64 command-line tools, but doesn't quite implement enough of the Linux syscalls to run a Linux window manager in order to run GUI programs. So it's certainly

Re: [swift-evolution] #if os(Windows) and MSVC/Cygwin Compatibility

> On May 3, 2016, at 2:44 AM, hitstergtd+swiftevo--- via swift-evolution > wrote: > > Why is there a need to support Cygwin/MingW and their variants as a > build target for Windows? MSVC is practically free these days. Cygwin at least is still valuable for providing

Re: [swift-evolution] #if os(Windows) and MSVC/Cygwin Compatibility

I wouldn't personally use a Cygwin or MinGW target these days, but I can see why a Cygwin target would be useful in a Swift context. I suspect most Swift code is either going to be written for iOS/Mac, or Linux server code, including third-party libraries. Lots of Swift code will probably have

[swift-evolution] Auto Unwrapping Of Optionals

I think the programmer knows best in a case like that. If I know it has a valid value, I wouldn't use an optional: class Test { var today: NSDate? = nil func test() { let today = self.today ?? NSDate() self.today = today print("Today is \(today)") // Would not be

Re: [swift-evolution] [Pitch] Reducing the bridging magic in dynamic casts

Confused about getAsNSString from bullet point 5, used again in bullet point 8 — the function wont compile for me: > Check whether a value is _ObjectiveCBridgeable to a class, or conversely, > that an object is _ObjectiveCBridgeable to a value type, and perform the > bridging conversion if so: >

Re: [swift-evolution] [Pitch] Reducing the bridging magic in dynamic casts

> On May 3, 2016, at 8:48 AM, J.D. Healy wrote: > > Confused about getAsNSString from bullet point 5, used again in bullet point > 8 — the function wont compile for me: There's a typo. getAsNSString needs to return an optional, `NSString?`, because the cast produces nil if

[swift-evolution] [Pitch] Reference storage for enum associated values

The following code currently has a retain cycle and memory leak: enum ParentChild { case SonOf(Parent) case DaughterOf(Parent) } class Parent { lazy var son: Child = Child(parentChild: .SonOf(self)) lazy var daughter: Child = Child(parentChild: .DaughterOf(self)) deinit {

[swift-evolution] [Proposal] Improving operator requirements in protocols

> 4. What do you think about adding a rule to disallow defining member > operators that don't satisfy a protocol requirement? > > Dmitri I’m wondering if we could go in the opposite direction, instead. If I’m understanding the proposal correctly, it only boils down to relaxing the rules about

Re: [swift-evolution] [Proposal] More Powerful Constraints for Associated Types

Sent from my iPad > On May 3, 2016, at 3:37 AM, Douglas Gregor via swift-evolution > wrote: > > > > Sent from my iPhone > >> On May 2, 2016, at 3:50 PM, David Hart wrote: >> >> Hi Doug, >> >> In the latest version of the proposal, which is

Re: [swift-evolution] #if os(Windows) and MSVC/Cygwin Compatibility

Why is there a need to support Cygwin/MingW and their variants as a build target for Windows? MSVC is practically free these days. Doesn't supporting multiple different ABI targets on Windows just complicate matters unnecessarily? Isn't MSVC enough as a build target? I am not dejecting; rather,

Re: [swift-evolution] [Proposal] More Powerful Constraints for Associated Types

Sent from my iPhone > On May 2, 2016, at 3:50 PM, David Hart wrote: > > Hi Doug, > > In the latest version of the proposal, which is now linked to a pull request, > I mentioned in the Detail Design section that the following syntax be valid: > > protocol R : Q where

Re: [swift-evolution] [Manifesto] Completing Generics

Sent from my iPhone > On May 2, 2016, at 3:58 PM, David Hart wrote: > > I’d like to continue moving Completing Generics forward for Swift 3 with > proposals. Can Douglas, or someone from the core team, tell me if the topics > mentioned in Removing unnecessary restrictions

Re: [swift-evolution] [Proposal] Improving operator requirements in protocols

FWIW, the problems with class inheritance and Equatable can be fixed by changing the definition of Equatable into using an associatedtype for the RHS: protocol Equatable { typealias EqualSelf = Self func == (lhs: Self, rhs: EqualSelf) -> Bool func != (lhs: Self, rhs: EqualSelf) ->

Re: [swift-evolution] proposal for a even simpler guard.. => guard!

I’m on the side of the ‘!’ at the moment. I see a lot of heat here going into hatred of the force unwrap operator, as if it should be avoided like the plague. I simply don’t see the need for such absolutism. It’s there for a reason. There are definitely use cases where use of the force unwrap

Re: [swift-evolution] proposal for a even simpler guard.. => guard!

Besides the legacy operator `!=`, isn't virtually every place you see ! potentially fatal, for some definition of potential? ;) On Tue, May 3, 2016 at 01:41 Dominik Pich via swift-evolution < swift-evolution@swift.org> wrote: > ;) yes. I know I can write let x = y! but IMHO THAT is too brief

Re: [swift-evolution] proposal for a even simpler guard.. => guard!

;) yes. I know I can write let x = y! but IMHO THAT is too brief again. I like the fact that guard makes you look what you do… it is a little bit like assert(x != nil) guard! let x = y it reads awesome and everybody can more easily see it is a potentially fatal & important call > On May 3,

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0017: Change Unmanaged to use UnsafePointer

On Thu, Apr 28, 2016, at 11:10 AM, Chris Lattner wrote: > Hello Swift community, > > The review of "SE-0017: Change Unmanaged to use UnsafePointer" begins now and > runs through May 3. The proposal is available here: > > >

Re: [swift-evolution] [Review] SE-0052: Change IteratorType post-nil guarantee

On Thu, Apr 28, 2016, at 11:12 AM, Chris Lattner via swift-evolution wrote: > Hello Swift community, > > The review of "SE-0052: Change IteratorType post-nil guarantee" begins now > and runs through May 3. The proposal is available here: > > >