Re: [swift-evolution] [Pitch] merge types and protocols back together with type

> But don't you mean the union type of all possible Collection types when you > write Any? No, I mean "an existential capable of holding any Collection". If I write Any, I mean "an existential capable of holding any Equatable Collection". If I write Any, I mean "an existential capable of hold

Re: [swift-evolution] `once` keyword for use with loops

Not to doubt the usefulness of this proposal in general, but your example is subsumed by simply declaring var result = "\(gen.next()!)" and proceeding with the rest of the example sans `once`. I think you'll also have to address how this is any different from dispatch_once or a DSL over the

[swift-evolution] `once` keyword for use with loops

​Hello Swift Evolution, Its not uncommon to have to do a piece of work only once or on the first iteration of a loop. Take for example producing a comma separated string from an Array: var result = "" let values = [1, 2, 3, 4, 5] var gen = values.generate() if let first = gen.

Re: [swift-evolution] Winding down the Swift 3 release

On 5/16/16, Chris Lattner wrote: > On May 16, 2016, at 2:27 PM, Eric Wing via swift-evolution > wrote: >>> I'm not an expert in the Linux communities needs and desires. That >>> said, >>> from what I understand, they don’t care at all about ABI stability, >>> since >>> everything is typically bu

Re: [swift-evolution] [Pitch] merge types and protocols back together with type

But don't you mean the union type of all possible Collection types when you write Any? I suggested `all<>` for the intersection type, and `any<>` for the union type, so that would be the same, wouldn't it? -Thorsten Am 17.05.2016 um 07:10 schrieb Brent Royal-Gordon via swift-evolution : >>

Re: [swift-evolution] [Pitch] merge types and protocols back together with type

> We've been over this a few times before on the list. I personally like naming > this thing "Any<…>" in the same vein as "AnyObject", "AnyClass", and > "AnySequence". I also see Thorsten (and in the past Brent's?) argument for > calling it "all" or "All", because it's enforcing multiple constra

Re: [swift-evolution] [Pitch] merge types and protocols back together with type

> Am 16.05.2016 um 21:29 schrieb Thorsten Seitz via swift-evolution > : > > >>> Am 15.05.2016 um 10:57 schrieb Adrian Zubarev via swift-evolution >>> : >>> >>> I think an important point is that `all<>` should NOT be restricted to >>> having only one reference or value type! >> >> This is

[swift-evolution] [Proposal]Simple pattern matching with Horspool algorithm

public extension CollectionType where Index : RandomAccessIndexType { @warn_unused_result func matchWith(pattern: C, @noescape isEquivalent: (Generator.Element, Generator.Element) throws -> Bool) rethrows -> Index? { let pattern_count = pattern.count.toIntMax() if co

Re: [swift-evolution] [Review] SE-0086: Drop NS Prefix in Swift Foundation

This sounds like a good idea. -Matt > On May 10, 2016, at 03:43, Geordie Jay via swift-evolution > wrote: > > >> Am 10.05.2016 um 12:26 schrieb Haravikk via swift-evolution >> mailto:swift-evolution@swift.org>>: >> >> >>> What is your evaluation of the proposal? >> Personally I’m a -1; I’d

Re: [swift-evolution] Winding down the Swift 3 release

On May 16, 2016, at 9:03 PM, Haris Amin wrote: > Hey Chris and team, > > This is great news. Any news on when/if libdispatch linux compatibility will > ship with Swift 3? Hi Haris, That is still the goal - I know that many folks are intensely interested in making this happen, and are contribu

[swift-evolution] Winding down the Swift 3 release

Hey Chris and team, This is great news. Any news on when/if libdispatch linux compatibility will ship with Swift 3? Thanks again. Haris > Hi Everyone, > > As we get deeper into the Swift 3 release cycle, we’re beginning to have a more precise understanding about what the release will shape up to

Re: [swift-evolution] Removing "_ in" from empty closures

+1 All the best, Nicholas Linked in: http://lnkd.in/328U22 On Mon, May 16, 2016 at 7:27 AM, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > on Fri May 13 2016, Joe Groff wrote: > > >> On May 13, 2016, at 9:13 AM, Rob Napier via swift-evolution < > swift-evolution@s

Re: [swift-evolution] [Review] SE-0086: Drop NS Prefix in Swift Foundation

-1 for all the reasons given so far. Foundation is not a Swift API and the NS prefixes help users understand that. Until Foundation gets an API rewrite that makes it feel native in the Swift ecosystem, it should be made very clear that it is a legacy API and not necessary following Swift best pract

Re: [swift-evolution] [Review] SE-0086: Drop NS Prefix in Swift Foundation

We (you) shouldn't remove the NS prefixes from most of the classes in the proposal. I agree with the reasons the other naysayers have given, but I'll try to restate them in my own words. Swift needs a better namespace/import system before these classes should lose the NS prefix. Right now, you can

Re: [swift-evolution] [Proposal] Remove behavior on AnyObject that allows any obj-c method to be called on it

I just saw these replies while searching for this thread, as I've been thinking of this proposal again recently. Regarding the API you point out, would it not be more appropriate for the API to change to provide an object conforming to some protocol definition instead? I don't like the idea of pos

Re: [swift-evolution] Winding down the Swift 3 release

On May 16, 2016, at 2:27 PM, Eric Wing via swift-evolution wrote: >> I'm not an expert in the Linux communities needs and desires. That said, >> from what I understand, they don’t care at all about ABI stability, since >> everything is typically built from source. > > Not exactly true. (I care.

Re: [swift-evolution] [Pitch] Parse expressions after 'as' and 'is' instead of just types

> On May 16, 2016, at 5:49 PM, Dan Appel wrote: > > Just to clarify: in your example, did you mean for DerivedA and DerivedB to > inherit from Base? Yeah, sorry about that. -Joe > > On Mon, May 16, 2016 at 4:18 PM Matthew Johnson via swift-evolution > wrote: > +1 > > Sent from my iPhone

Re: [swift-evolution] [Pitch] Parse expressions after 'as' and 'is' instead of just types

Just to clarify: in your example, did you mean for DerivedA and DerivedB to inherit from Base? On Mon, May 16, 2016 at 4:18 PM Matthew Johnson via swift-evolution < swift-evolution@swift.org> wrote: > +1 > > Sent from my iPhone > > > On May 16, 2016, at 4:06 PM, Joe Groff via swift-evolution < >

Re: [swift-evolution] [Pitch] Parse expressions after 'as' and 'is' instead of just types

+1 Sent from my iPhone > On May 16, 2016, at 4:06 PM, Joe Groff via swift-evolution > wrote: > > Currently, we parse a type after 'as[?!]' and 'is'. This is mostly what you'd > expect, but does lead to problems when an 'as' expression appears as part of > a comparison: > >20 as Int64 <

Re: [swift-evolution] [Review] SE-0081: Move where clause to end of declaration

Regards (From mobile) > On May 16, 2016, at 8:16 PM, Thorsten Seitz via swift-evolution > wrote: > > >>> Am 16.05.2016 um 17:04 schrieb Karl via swift-evolution >>> : >>> >>> internal func _arrayOutOfPlaceReplace >>> >>> (_ source: inout B, _ bounds: Range, _ newValues: C, _ insertCount:

Re: [swift-evolution] Could enums have their rawValue type inferred?

> This might open a larger can of worms than I imagine, but what do you folks > think about using the `rawValue` of an enum when that rawValue is a fit for > the expected type? No. An enum case is something quite distinct from its raw value. If you just want a convenient way to write some part

Re: [swift-evolution] Winding down the Swift 3 release

> On May 16, 2016, at 2:53 PM, John McCall via swift-evolution > wrote: > >> On May 16, 2016, at 2:06 PM, Chris Lattner via swift-evolution >> wrote: >>> On May 16, 2016, at 11:33 AM, Tim Hawkins wrote: >>> >>> At what point would you consider the Linux product to be viable for >>> product

Re: [swift-evolution] Winding down the Swift 3 release

> On May 16, 2016, at 2:06 PM, Chris Lattner via swift-evolution > wrote: >> On May 16, 2016, at 11:33 AM, Tim Hawkins > > wrote: >> >> At what point would you consider the Linux product to be viable for >> production server side application development. Do you th

[swift-evolution] [Review] Amendment: SE-0039: Moderning Playground Literals

Original proposal: https://github.com/apple/swift-evolution/blob/master/proposals/0039-playgroundliterals.md Pull request for modification: https://github.com/apple/swift-evolution/pull/324

Re: [swift-evolution] Winding down the Swift 3 release

> On May 16, 2016, at 4:27 PM, Eric Wing via swift-evolution > wrote: > >> I'm not an expert in the Linux communities needs and desires. That said, >> from what I understand, they don’t care at all about ABI stability, since >> everything is typically built from source. >> >> -Chris >> >> >

Re: [swift-evolution] Winding down the Swift 3 release

> I'm not an expert in the Linux communities needs and desires. That said, > from what I understand, they don’t care at all about ABI stability, since > everything is typically built from source. > > -Chris > > Not exactly true. (I care.) Video games (e.g. Steam/Linux) care deeply about ABI stab

Re: [swift-evolution] [Pitch] Parse expressions after 'as' and 'is' instead of just types

> On May 16, 2016, at 2:06 PM, Joe Groff via swift-evolution > wrote: > > Looking to the future, many people have also expressed interest in the > ability to do dynamic type checks against metatype values, not only static > types, as in: +1 -- I’ve definitely needed this before, and ended up

Re: [swift-evolution] [Pitch] Parse expressions after 'as' and 'is' instead of just types

+1 - Dave Sweeris > On May 16, 2016, at 4:06 PM, Joe Groff via swift-evolution > wrote: > > Currently, we parse a type after 'as[?!]' and 'is'. This is mostly what you'd > expect, but does lead to problems when an 'as' expression appears as part of > a comparison: > > 20 as Int64 < y

Re: [swift-evolution] Winding down the Swift 3 release

On May 16, 2016, at 12:29 PM, Dan Stenmark wrote: > With the generics and ABI stability goals getting pushed out to a future > release, how does that affect the plans for Swift concurrency features? Will > the topic still be explored in the Swift 4 timeframe, or do you expect that > discussion

Re: [swift-evolution] Winding down the Swift 3 release

> On May 16, 2016, at 11:53 AM, Ryan Lovelett > wrote: > > On Mon, May 16, 2016, at 11:18 AM, Chris Lattner via swift-evolution > wrote: >> Hi Everyone, >> >> As we get deeper into the Swift 3 release cycle, we’re beginning to have >> a more precise understanding about what the release will sh

[swift-evolution] [Pitch] Parse expressions after 'as' and 'is' instead of just types

Currently, we parse a type after 'as[?!]' and 'is'. This is mostly what you'd expect, but does lead to problems when an 'as' expression appears as part of a comparison: 20 as Int64 < y as Int64 // error, '>' expected to close generic parameter list Int64 Looking to the future, many peo

Re: [swift-evolution] Winding down the Swift 3 release

> On May 16, 2016, at 11:33 AM, Tim Hawkins wrote: > > At what point would you consider the Linux product to be viable for > production server side application development. Do you think that goal has > been achieved in swift 3.0. Or is it going to have to wait for the ABI lock > down. > I'm

[swift-evolution] [Accepted] SE-0092: Typealiases in protocols and protocol extensions

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0092-typealiases-in-protocols.md The new proposal for SE-0092 "Typealiases in protocols and protocol extensions” is proactively approved for Swift. The core team consider this as an obvious follow-on to SE-0011, and

Re: [swift-evolution] Idea: Named extensions

Ya I didn’t see that email until after I wrote it up. If it does gain traction, I wouldn’t mind writing a proposal and tabling it for now. Would just like to see some discussion on it, but I don’t want to detract from the current goals! Brandon > On May 16, 2016, at 4:25 PM, T.J. Usiyan wrot

Re: [swift-evolution] Idea: Named extensions

Here is an attempt to express myself better :) Objective-C to Swift category to extension conversion loss of descriptive name Objective-C category: @interface NSAttributedString (NSAttributedStringDocumentFormats) // Methods initializing the receiver contents with an external document data. opt

Re: [swift-evolution] Idea: Named extensions

I have wanted this feature and floated it a while back. I hope we can get some traction this time but I doubt it will happen soon since additive features are tabled for a time. On Mon, May 16, 2016 at 3:47 PM, Brandon Knope via swift-evolution < swift-evolution@swift.org> wrote: > I think requiri

Re: [swift-evolution] Idea: Named extensions

I think requiring them to be in comments is what’s going to prevent their adoption. My fundamental stance is that these awesome features that are required in comments will be overlooked by people because: • You have to remember the specific syntax • There is no code completion which means you h

Re: [swift-evolution] Winding down the Swift 3 release

With the generics and ABI stability goals getting pushed out to a future release, how does that affect the plans for Swift concurrency features? Will the topic still be explored in the Swift 4 timeframe, or do you expect that discussion be deferred to 5 or beyond? Dan > On May 16, 2016, at 8:

Re: [swift-evolution] [Pitch] merge types and protocols back together with type

> Am 15.05.2016 um 10:57 schrieb Adrian Zubarev via swift-evolution > : > >> I think an important point is that `all<>` should NOT be restricted to >> having only one reference or value type! > > This is a little problematic and I’m not a compiler expert so from my > perspective I could allow

Re: [swift-evolution] Idea: Named extensions

Most of the Swift docs markup tech is both very new and still evolving. I'm trying to evangelize the technology, and there are now five markup items that actually tie into the code completion engine: Three new doc comment fields, namely - keyword:, - recommended: and - recommendedover:, allow S

Re: [swift-evolution] Idea: Named extensions

I have never seen anyone use this. Why? Because it is relatively unknown and not very “pretty” in my opinion. In the ideal world, everyone would have perfectly formatted and up to date comment, but I am not convinced this is usually the case. It’s good for IDE documenting, but: • Online tutoria

Re: [swift-evolution] Idea: Named extensions

Or better yet, the 'Keyword" token offers searchable content that can relate one extension to the other. /// - Keyword: Lifecycle extension -- Erica > On May 16, 2016, at 11:33 AM, Michael Peternell via swift-evolution > wrote: > > Why not just use a (documentation) comment? > > /// The Li

Re: [swift-evolution] Idea: Named extensions

> On May 16, 2016, at 1:59 PM, Brandon Knope wrote: > > Do you have a link to your proposal? The part relevant to this thread is in the section “Interactions with other features” https://github.com/anandabits/swift-evolution/blob/partial-initializers/proposals/-partial-initializers.md >

Re: [swift-evolution] Idea: Named extensions

Do you have a link to your proposal? Thanks, Brandon > On May 16, 2016, at 2:58 PM, Matthew Johnson wrote: > > > > Sent from my iPad > >> On May 16, 2016, at 12:33 PM, Michael Peternell via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> Why not just use a (documentation

Re: [swift-evolution] Idea: Named extensions

Sent from my iPad > On May 16, 2016, at 12:33 PM, Michael Peternell via swift-evolution > wrote: > > Why not just use a (documentation) comment? > > /// The Lifecycle extension: > extension ViewController { There have been discussions about possibly allowing extensions to have stored prope

Re: [swift-evolution] Winding down the Swift 3 release

On Mon, May 16, 2016, at 11:18 AM, Chris Lattner via swift-evolution wrote: > Hi Everyone, > > As we get deeper into the Swift 3 release cycle, we’re beginning to have > a more precise understanding about what the release will shape up to be. > Ted posted details of the Swift 3 release process la

Re: [swift-evolution] [Review] SE-0085: Package Manager Command Names

Hello Swift community, The Swift package manager core team met last week to discuss this proposal, and we ultimately *accepted* it relatively unchanged. I have amended the proposal to include more information on the alternatives discussed: https://github.com/apple/swift-evolution/blob/master/

Re: [swift-evolution] Winding down the Swift 3 release

At what point would you consider the Linux product to be viable for production server side application development. Do you think that goal has been achieved in swift 3.0. Or is it going to have to wait for the ABI lock down. I'm weighting the wisdom of possibly using Swift on linux for microservic

Re: [swift-evolution] Idea: Named extensions

Because to me this seems too indirect and not explicit enough. I think doing it explicitly: • Makes your intent much clearer • Forces you to think about not throwing everything into one big extension (i.e. somewhat more binding than a comment that can easily be looked over) • Shows that it’s a fi

Re: [swift-evolution] [Review] SE-0081: Move where clause to end of declaration

> Am 16.05.2016 um 17:04 schrieb Karl via swift-evolution > : > >> internal func _arrayOutOfPlaceReplace >> >> (_ source: inout B, _ bounds: Range, _ newValues: C, _ insertCount: Int) >> where >> C.Iterator.Element == B.Element, >> B.Index == Int >> { >> >> Now only the relatively unimportant

Re: [swift-evolution] Winding down the Swift 3 release

On May 16, 2016, at 10:38 AM, Goffredo Marocchi wrote: > Quite sad we could not get into ABI stability for Swift 3... but are we > talking Swift 3.1 or 4.0? We’ll start discussing post-3.0 releases in August. Until Swift 3 is really wound down, it is almost impossible to make forward looking p

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

> On May 16, 2016, at 9:21 AM, Matthew Johnson wrote: > > >>> On May 16, 2016, at 1:17 AM, Tyler Fleming Cloutier >>> wrote: >>> >>> >>> On May 15, 2016, at 11:48 AM, Dave Abrahams via swift-evolution >>> wrote: >>> >>> >>> on Mon May 09 2016, Matthew Johnson wrote: >>> > On May

Re: [swift-evolution] [Pitch] merge types and protocols back together with type

The proposal is moved to: [Proposal] New mechanism to combine Types with/or  Protocols Feel free to review this version in the new thread before I submit a pull request. --  Adrian Zubarev Sent with Airmail Am 16. Mai 2016 bei 11:51:32, Adrian Zubarev (adrian.zuba...@devandartist.com) schrieb:

Re: [swift-evolution] Winding down the Swift 3 release

Quite sad we could not get into ABI stability for Swift 3... but are we talking Swift 3.1 or 4.0? Sent from my iPhone > On 16 May 2016, at 17:43, Chris Lattner via swift-evolution > wrote: > > >> On May 16, 2016, at 9:29 AM, David Sweeris wrote: >> >> >>> On May 16, 2016, at 10:18 AM, Chr

Re: [swift-evolution] Idea: Named extensions

Why not just use a (documentation) comment? /// The Lifecycle extension: extension ViewController { ... -Michael > Am 16.05.2016 um 18:26 schrieb Brandon Knope via swift-evolution > : > > I like to separate methods into their own logical extensions so similar > methods are grouped together. I

Re: [swift-evolution] Could enums have their rawValue type inferred?

> automatically cast rawValue when assigning an enum value to a variable or argument of the type of the enum's raw value That's exactly what I'm thinking, Leonardo. I was a little bit trying to avoid specifics because I don't understand the differences between autocasting and inference. There's a

[swift-evolution] [Proposal] New mechanism to combine Types with/or Protocols

I open a new thread just for clarity. This proposal was started two weeks ago in a discussion thread where I talked to the community and refined the proposal over a few past days. The overall response was positive to this proposal. Original thread: [Pitch] merge types and protocols back together

Re: [swift-evolution] Union instead of Optional

> Am 16.05.2016 um 17:29 schrieb Michael Peternell via swift-evolution > : > > >> Am 16.05.2016 um 12:07 schrieb Austin Zheng via swift-evolution >> : >> >> Precisely. To me unions are to enums with associated type the same way >> tuples are to structs. One is named, has well-defined semanti

Re: [swift-evolution] Winding down the Swift 3 release

> On May 16, 2016, at 9:29 AM, David Sweeris wrote: > > >> On May 16, 2016, at 10:18 AM, Chris Lattner via swift-evolution >> wrote: >> >> That said, it is also clear at this point that some of the loftier goals >> that we started out with aren’t going to fit into the release - including >

Re: [swift-evolution] Winding down the Swift 3 release

> On May 16, 2016, at 10:18 AM, Chris Lattner via swift-evolution > wrote: > > That said, it is also clear at this point that some of the loftier goals that > we started out with aren’t going to fit into the release - including some of > the most important generics features needed in order to

[swift-evolution] [META] Using escapes in Swift Evolution Proposal discussion links

The standard Swift Evolution proposal template includes the following introduction section: ## Introduction A short description of what the feature is. Try to keep it to a single-paragraph "elevator pitch" so the reader unde

[swift-evolution] Idea: Named extensions

I like to separate methods into their own logical extensions so similar methods are grouped together. I do this mostly with Cocoa Touch where I like all view life cycle methods to be in the same extension: extension ViewController { override func viewDidLoad() { } override func

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

> On May 16, 2016, at 1:17 AM, Tyler Fleming Cloutier > wrote: > >> >> On May 15, 2016, at 11:48 AM, Dave Abrahams via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> >> on Mon May 09 2016, Matthew Johnson > > wrote: >> On May 8, 2

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

> On May 16, 2016, at 1:38 AM, Tyler Fleming Cloutier via swift-evolution > wrote: > >> >> On May 15, 2016, at 11:17 PM, Tyler Fleming Cloutier via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >>> >>> On May 15, 2016, at 11:48 AM, Dave Abrahams via swift-evolution >>> ma

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

> On May 16, 2016, at 1:39 AM, Dave Abrahams wrote: > > > on Sun May 15 2016, Tyler Fleming Cloutier > wrote: > >>On May 15, 2016, at 11:48 AM, Dave Abrahams via swift-evolution >> wrote: >> >>on Mon May 09 2016, Matthew Johnson wrote: >> >>

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

> On May 15, 2016, at 1:48 PM, Dave Abrahams wrote: > > > on Mon May 09 2016, Matthew Johnson > wrote: > >>> On May 8, 2016, at 1:51 AM, Dave Abrahams wrote: >>> >>> >>> on Sat May 07 2016, Andrew Trick wrote: >>> >> On May 7, 2016, at 2:04 PM,

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

> On May 16, 2016, at 10:14 AM, Dave Abrahams wrote: > > > on Mon May 16 2016, Matthew Johnson wrote: > >>> On May 15, 2016, at 1:53 PM, Dave Abrahams wrote: >>> >>> >>> on Fri May 13 2016, Matthew Johnson >> > wrote: >>> >> If we’re going to hide th

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

> On May 15, 2016, at 2:01 PM, Dave Abrahams wrote: > > > on Fri May 13 2016, Matthew Johnson > wrote: > >> Sent from my iPad >> >>> On May 13, 2016, at 9:12 AM, Dave Abrahams wrote: >>> >>> on Mon May 09 2016, Matthew Johnson wrote: M

Re: [swift-evolution] Union instead of Optional

Unlike sum types, such as Swift enums, unions don't have parametricity, because (T \union Nil) \union Nil == T \union Nil. This means that things like collections containing Optionals don't just work, since it becomes impossible for operations like 'find' to distinguish 'nil' as a value in the c

Re: [swift-evolution] [RFD] Non-Self Protocol Requirements

On 16.05.2016 18:06, Patrick Smith via swift-evolution wrote: let foo: [Double] = Double[int32, int8, double, cgfloat, float] // As if you had written Double(…) around each item I really like this suggestion. Actually IMO we don't need explicit type declaration here: // clearly it is an arra

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

hi there, just skimmed through the bigger part of this thread — it's a really interesting discussion, but wouldn't it be worth a topic on its own? The title of this message addresses a much simpler question (that imho still deserves some answers ;-) Tino

Re: [swift-evolution] Union instead of Optional

> Am 16.05.2016 um 12:07 schrieb Austin Zheng via swift-evolution > : > > Precisely. To me unions are to enums with associated type the same way tuples > are to structs. One is named, has well-defined semantics, can conform to > protocols, can have complex internal structure, can have methods,

Re: [swift-evolution] Union instead of Optional

> Precisely. To me unions are to enums with associated type the same way tuples > are to structs. Me too — and I think it would be beautiful if it could be modeled that way, so that there is always a pair of a named and an anonymous variant for functions (closures), types (structs) and enums (ye

[swift-evolution] Winding down the Swift 3 release

Hi Everyone, As we get deeper into the Swift 3 release cycle, we’re beginning to have a more precise understanding about what the release will shape up to be. Ted posted details of the Swift 3 release process last week (https://swift.org/blog/swift-3-0-release-process/) and I just updated the

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

on Mon May 16 2016, Matthew Johnson wrote: >> On May 15, 2016, at 1:53 PM, Dave Abrahams wrote: >> >> >> on Fri May 13 2016, Matthew Johnson > > wrote: >> > If we’re going to hide the implementation details maybe it’s worth > taking advantage of the

Re: [swift-evolution] [Proposal/Pitch] Function decorators

> On 16 May 2016, at 16:25, Erica Sadun wrote: > >> On May 8, 2016, at 10:33 AM, Karl Wagner via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> >>> On 4 May 2016, at 00:46, Aleksandar Petrovic via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >>> Hi s

Re: [swift-evolution] [RFD] Non-Self Protocol Requirements

Yes, something like this would be handy! Even the ability to coerce from one type to another, if that destination type has a keyless initialiser for the source type. Here’s some imaginary syntax for with Erica’s array example. I would prefer a way to not have a separate type for ‘DoubleSource’

Re: [swift-evolution] [Review] SE-0081: Move where clause to end of declaration

> internal func _arrayOutOfPlaceReplace > > (_ source: inout B, _ bounds: Range, _ newValues: C, _ insertCount: Int) > where > C.Iterator.Element == B.Element, > B.Index == Int > { > > Now only the relatively unimportant details—that the buffer and collection > must have elements of the same

Re: [swift-evolution] Union instead of Optional

I don't really get it why the compiler is to complain about the if block not having an else in this case. That seems like a bug that will push us to write unnecessary code. The compiler is not capable of inferring there are more conditions to evaluate in an if statement opposed to a switch state

Re: [swift-evolution] [Proposal/Pitch] Function decorators

Well, yes and no. A decorator receives a method and returns a new method, and it's up to implementation what will happen in the new method - it can perform some operations before calling the original method, or doing something after the original method is called, or not calling the original meth

[swift-evolution] [Review] SE-0041: Updating Protocol Naming Conventions for Conversions

>* What is your evaluation of the proposal? +1. Having consistent conventions makes sense to me. I’d prefer `Initializable` to `Creatable` which sounds weird to me, but otherwise sounds great. >* Is the problem being addressed significant enough to warrant a change to >Swift? I think semantic

Re: [swift-evolution] [Review] SE-0041: Updating Protocol Naming Conventions for Conversions

On Tue, May 10, 2016 at 11:48 AM Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote: > Hello Swift community, > > The review of "SE-0041: Updating Protocol Naming Conventions for > Conversions" begins now and runs through May 16. The proposal is available > here: > > > https://gi

Re: [swift-evolution] [Proposal/Pitch] Function decorators

> On May 8, 2016, at 10:33 AM, Karl Wagner via swift-evolution > wrote: > > >> On 4 May 2016, at 00:46, Aleksandar Petrovic via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> Hi swift-evolution, >> >> I want to apologize in advance for my clumsy English. It's (obviously)

[swift-evolution] [RFD] Non-Self Protocol Requirements

The following situation has come up for me now and then: I want to work with groups of types that share a common behavior, but that behavior is not sourced in the implementation of the Self type but rather in a secondary type. Specifically, could Swift be extended to introduce a protocol requir

Re: [swift-evolution] Union instead of Optional

I can understand this proposal nite and I don't really think they're related to enums at all. You can today achieve the very same behaviour using an empty protocol. protocol P { } class A : P { } class B : P { } struct C : P { } func test(value : P) { } IMO, the proposed syntax will only crea

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

> On May 15, 2016, at 1:53 PM, Dave Abrahams wrote: > > > on Fri May 13 2016, Matthew Johnson > wrote: > >> Sent from my iPad >> >>> On May 13, 2016, at 9:19 AM, Dave Abrahams wrote: >>> >>> on Mon May 09 2016, Matthew Johnson wrote: R

Re: [swift-evolution] [Review] SE-0088: Modernize libdispatch for Swift 3 naming conventions

Hi, I’m a +1 on the proposal, I think it’s a no brainer, but I do have one question... What is the reasoning behind repeating the module name in the type name? e.g we have `Dispatch.DispatchQueue`. Why not `Dispatch.Queue`? It seems a bit pointless for the Swift team to go to all that effort t

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

FWIW, totally agree with this opinion. I also don't understand why "poor beginner who would start typing swift code before reading the manual" becomes so important when we decide to accept or not some new feature or change. Are we working on language that must be used just to teach children/beg

[swift-evolution] [proposal] Union Type

Union is far better then generic enum/protocol solution. * It can extend the original enum and make it powerful. enum ResultDataType { case Music case Video case File } enum FailureType { case HTTP404 case HTTP502 } enum FailureTypev2 { case HTTP45

Re: [swift-evolution] Union instead of Optional

Hi Austin, let me repeat the example so that clarify my point from this example. protocol cannot do this: func input(value: ProtocolForABC) { print(value.someCommonProperty) if value is A { } else if value is B { } else if value is C { } else {

Re: [swift-evolution] Union instead of Optional

I like the justification of unions as lightweight restricted ad-hoc enums. Definitely agreed with you in that the compiler will have to do more work, and should be able to handle the implicit conversion without going bonkers. Thanks! Austin > On May 16, 2016, at 3:35 AM, Haravikk wrote: > >

Re: [swift-evolution] Union instead of Optional

I'm sorry, but I don't understand the point you are trying to make. If you pass in a value of type (A | B | C) to a function, what might you want to do with that value? If you want to do one thing if the value is type A, something else if the value is type B, and something else if the value is

Re: [swift-evolution] Union instead of Optional

> On 16 May 2016, at 11:17, Austin Zheng via swift-evolution > wrote: > > If A, B, and C are not related via protocol or class inheritance, then there > is almost nothing you can do with value. Otherwise you still need to test > against the concrete type using a case statement or a if-else la

Re: [swift-evolution] Union instead of Optional

Consider this case: class A { var someCommonProperty: Int = 0 } class B { var someCommonProperty: Int = 0 } class C { var someCommonProperty: Int = 0 } protocol UnionABC { var someCommonProperty: Int } extension A: UnionABC {} extension B: UnionABC {} extension C: UnionABC {}

Re: [swift-evolution] Union instead of Optional

This doesn't explain how I can use 'value' once an A() is passed into the function: func input(value: (A | B | C)) { } If A, B, and C are not related via protocol or class inheritance, then there is almost nothing you can do with value. Otherwise you still need to test against the concrete type

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

> On May 16, 2016, at 2:16 AM, Dave Abrahams wrote: > > > on Mon May 16 2016, Tyler Fleming Cloutier wrote: > Super interesting talk! But consider: isn't a single value type able to represent *multiple* ethereal types? >>> >>> “ethereal?” Does he really use that term?

Re: [swift-evolution] Union instead of Optional

Precisely. To me unions are to enums with associated type the same way tuples are to structs. One is named, has well-defined semantics, can conform to protocols, can have complex internal structure, can have methods, etc. The other is ad-hoc and lightweight, easy to define at the site of use, be

Re: [swift-evolution] Union instead of Optional

Yes, enums are like explicit named type unions whereas ad hoc type unions can be useful exactly because they are ad hoc. It is kind of like named functions vs. anonymous functions. Both have their place. Ceylon makes tremendous use of union and intersection types. While they don’t have enums in

Re: [swift-evolution] [Pitch] merge types and protocols back together with type

I’ve rewritten my proposal towards the Generic Manifesto for Swift 3. I’ve polished a lot of thoughts to make everything as clear as possible. I still have to write Motivation and Proposed solution, but everything else seems to be rock solid - I’d say. Again `All<>` should not intersect but mer

Re: [swift-evolution] [Review] SE-0081: Move where clause to end of declaration

+1. Non-type generic parameters can be handled if/when they are proposed after Swift 3. There have to be better ways to encourage proper organization of the elements of a method header than forcing a redundant and non-obvious conformance to 'Any'; if this is mandatory the proposal is fatally fla

  1   2   >