Re: [swift-evolution] [Proposal] Separate protocols and interfaces

This would be wonderful - is it something that could happen in the Swift 3 timeframe? Is it something that myself or someone else could work on a formal proposal for? -DW > On Jan 3, 2016, at 4:17 PM, Douglas Gregor via swift-evolution > wrote: > > >> On Jan 3,

[swift-evolution] Idea: delegates as protocols and property types with specialised behaviours.

At the moment, the delegate pattern is just one use of protocols. We create a protocol with a set of declared functions, implemented either in a protocol extension or in the conforming type - the delegate - and another type calls functions of its delegate, notifying them when certain events occur.

Re: [swift-evolution] Empower String type with regular expression

+1 on first-class regex support/pattern matching on regex patterns. There was a thread a while ago discussing compile-time code generation, and if I recall correctly one of the stated use cases was 'compiling'/'building' (don't know the real terminology) regex literals at compile-time. Is there a

Re: [swift-evolution] use standard syntax instead of "do" and "repeat"

> On Jan 3, 2016, at 1:37 PM, Dave Abrahams wrote: > >> >> On Jan 3, 2016, at 10:21 AM, Matthew Johnson wrote: >> >>> >>> On Jan 3, 2016, at 12:12 PM, Dave Abrahams via swift-evolution >>> wrote: >>> >>> On Jan

Re: [swift-evolution] [Proposal] Separate protocols and interfaces

> On Jan 3, 2016, at 8:52 PM, Drew Crawford via swift-evolution > wrote: > > I offer a +1, but I have two criticisms of the proposal. > > The first is that the example given in the proposal is stated a lot more > strongly than is true: > >> func compareTwo(first:

Re: [swift-evolution] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

+1 from me too. (My vote takes into account the various alternatives were put on the table and weeded down thoughtfully to the one we're voting on.) -- E > On Jan 3, 2016, at 5:57 AM, T.J. Usiyan via swift-evolution > wrote: > > +1 from me. It is a solid change

Re: [swift-evolution] [Proposal]: Free the '$' Symbol!

That's an interesting issue, I think you're right. Technically I think it would only be a problem if you omitted spaces: "a<$>b", since infix identifiers aren't allowed to have a space on one side but not the other (thus "a <$> b" couldn't be ">(<(a, $), b)", but "a<$>b" could). Jacob On Sun,

Re: [swift-evolution] Declaring a function that always returns nil

You could also use type inference on the return type: 1> func returnsNil(errCode: Int) -> T? { 2. print(errCode) 3. return nil 4. } 5> func returnsAnOptional() -> Int? { 6. return returnsNil(5) 7. } > On Jan 3, 2016, at 7:51 PM, Jeff Kelley via

Re: [swift-evolution] use standard syntax instead of "do" and "repeat"

> On Jan 3, 2016, at 7:38 PM, Matthew Johnson > wrote: > >> >> On Jan 3, 2016, at 9:31 PM, Tyler Fleming Cloutier via swift-evolution >> > wrote: >> >> Please see inline

Re: [swift-evolution] Declaring a function that always returns nil

Cleaned up a bit after I tried to actually use it: > extension Optional { > static func returnsNil(errorCode: Int) -> Wrapped? { > logError(errorCode) > return nil > } > } > > extension Int { > func foo() -> Int? { > return .returnsNil(12) > } > } You

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] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

>> Swift has proven it can thrive in secrecy, so I don't think the whole open >> community is a necessity — but as it is now, we should hold transparency in >> high esteem and not start faking democracy. > > I’m confused, what are you saying? No decision has been made here, I’m not > aware

Re: [swift-evolution] [Proposal]: Free the '$' Symbol!

Is it considered infeasible for any characters to be allowed in both identifiers and operators? On Sun, Jan 3, 2016 at 1:23 PM, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote: > > > On Jan 2, 2016, at 11:53 PM, Brent Royal-Gordon via swift-evolution < >

Re: [swift-evolution] use standard syntax instead of "do" and "repeat"

Indeed both are reasonable but perhaps suboptimal. Consider the following potential changes. // Assume this code is included for the below examples. func myThrowingFunc() throws -> String { if drand48() < 0.5 { throw NSError(domain: "", code: 0, userInfo: nil) } return "" }

Re: [swift-evolution] use standard syntax instead of "do" and "repeat"

> On 3 Jan, 2016, at 10:51, David Waite wrote: > > One possible approach if it was desirable to not have this used arbitrarily > in place of do+try, and to avoid looking too much like exception syntax: > instead define rethrows blocks: > > func

Re: [swift-evolution] [Proposal] Separate protocols and interfaces

> On Jan 3, 2016, at 6:48 AM, Антон Жилин via swift-evolution > wrote: > > Introduction of interfaces will clean up the current blend of static and > dynamic protocols, and solve at least three popular issues. > Please see: >

Re: [swift-evolution] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

I'd argue that there's been such a big discussion because it's basically a bikeshed. This is an easy topic for everyone to understand so there's low barrier to entry, and it basically boils down to "what should we name this thing?" which is something everybody can easily form an opinion on.

Re: [swift-evolution] use standard syntax instead of "do" and "repeat"

> On Jan 3, 2016, at 9:31 PM, Tyler Fleming Cloutier via swift-evolution > wrote: > > Please see inline comments. > > >> On Jan 3, 2016, at 6:48 PM, Tyler Fleming Cloutier via swift-evolution >> > wrote:

Re: [swift-evolution] [Proposal]: Free the '$' Symbol!

We need a token to be unambiguously an operator or identifier - we can have different rules for the leading and subsequent characters though. -Chris > On Jan 3, 2016, at 6:02 PM, Jacob Bandes-Storch wrote: > > Is it considered infeasible for any characters to be allowed in

[swift-evolution] Declaring a function that always returns nil

It should be possible to declare a function that returns only nil, and have its return type be substitutable for any function that returns and Optional. This is something like having a bottom type but not really. What I mean is: func returnsNil(errCode:Int) -> nil { logError(errCode) //

Re: [swift-evolution] [Proposal] Separate protocols and interfaces

> On Jan 3, 2016, at 10:25 AM, Антон Жилин via swift-evolution > wrote: > > The problem with syntax of "existential protocol" and "protocol" is that the > first should actually be default, and easier to write. > > We should prefer static to dynamic. These two

Re: [swift-evolution] [Proposal] Separate protocols and interfaces

+1 to "opening" values of existential type, I remember trying (and failing) to do this when Swift 1 came out. Being able to capture the dynamic type of an object at runtime and do stuff with it would be incredible. Austin On Sun, Jan 3, 2016 at 4:19 PM, David Waite via swift-evolution <

Re: [swift-evolution] [Proposal] Separate protocols and interfaces

I offer a +1, but I have two criticisms of the proposal. The first is that the example given in the proposal is stated a lot more strongly than is true: > func compareTwo(first: Comparable, _ second: Comparable) -> Int { // error! > if first < second { > return -1 > } > //... > } >

Re: [swift-evolution] [Proposal] Separate protocols and interfaces

> On Jan 3, 2016, at 9:08 PM, Drew Crawford wrote: > >> Existentials for protocols with Self and / or associated type requirements >> would require bindings for Self and / or the associated type(s). At least >> when you use a member that contains Self and / or an

Re: [swift-evolution] use standard syntax instead of "do" and "repeat"

> On Jan 3, 2016, at 6:36 PM, Matthew Johnson via swift-evolution > wrote: >>> >>> I agree that requiring this is not likely to result in improved error >>> handling and thus is not a strong argument in favor of it. >>> >>> IMO the purpose of requiring “try” to be

Re: [swift-evolution] [Proposal]: Free the '$' Symbol!

Le 3 janv. 2016 à 13:40, Félix Cloutier via swift-evolution a écrit : > As I recall it, there is no overlap between operator characters and > identifier characters. If it's not in the operator set, it's effectively > reserved for identifiers. It's funny that ¢, £,

Re: [swift-evolution] Customized Inline Init Closure

Hey there! As a suggestion, check out this simple yet very interesting project called Then by @devxoul. Best, — A > On Jan 3, 2016, at 1:37 AM, Weston Catron via swift-evolution > wrote: > > Ability to write an initializer while

Re: [swift-evolution] [swift-evolution-announce] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

On Sun, Jan 3, 2016, at 03:41 AM, Loïc Lecrenier via swift-evolution wrote: > Hi Drew, > > Thanks for the review, just a quick remark: > > “Real” type aliases are already forbidden inside protocols, so this proposal > wouldn’t change that. > (According to the grammar, a protocol body can only

Re: [swift-evolution] [Proposal]: Free the '$' Symbol!

On Sun, Jan 3, 2016, at 12:55 PM, Michel Fortin via swift-evolution wrote: > Le 3 janv. 2016 à 13:40, Félix Cloutier via swift-evolution > a écrit : > > As I recall it, there is no overlap between operator characters and > > identifier characters. If it's not in the

Re: [swift-evolution] [Proposal] Separate protocols and interfaces

> Existentials for protocols with Self and / or associated type requirements > would require bindings for Self and / or the associated type(s). At least > when you use a member that contains Self and / or an associated type in its > signature. So the previous example will always fail to

Re: [swift-evolution] use standard syntax instead of "do" and "repeat"

Please see inline comments. > On Jan 3, 2016, at 6:48 PM, Tyler Fleming Cloutier via swift-evolution > wrote: > > Indeed both are reasonable but perhaps suboptimal. Consider the following > potential changes. > > > // Assume this code is included for the below

Re: [swift-evolution] Customized Inline Init Closure

I believe you’re referring to this https://gist.github.com/erica/eb32feb22ba99629285a currently being developed. I was initially limiting this proposal to initializers, specifically overriding them verses immediately following them. This is

Re: [swift-evolution] Declaring a function that always returns nil

IMO, this is the best way to approach it. Félix > Le 3 janv. 2016 à 22:54:17, Jack Lawrence via swift-evolution > a écrit : > > You could also use type inference on the return type: > > 1> func returnsNil(errCode: Int) -> T? { > 2. print(errCode) > 3.

Re: [swift-evolution] [Proposal]: Free the '$' Symbol!

I have been thinking about this topic a lot, but not '$' symbol, rather the tools to create DSLs within Swift to enable productive & meaningful special casing. (Ruby's Rake vs Make/GNUMake come to mind a lot, or Ruby's Sinatra web framework come to mind, perhaps Python's Flask to a lesser

Re: [swift-evolution] [Proposal] Separate protocols and interfaces

> On Jan 3, 2016, at 9:14 PM, Drew Crawford wrote: > > Sure, here's the start of the thread: > https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001856.html > >

Re: [swift-evolution] Customized Inline Init Closure

Thanks! Then looks very interesting and I’ll reach out to the lead there and see if they’re interested in working together. It definitely highlights similar readability issues I had outlined. I’m curious if there are compiler or other advantages to initializing more properties before continuing

Re: [swift-evolution] [SR-119] AnySequence --> Any*Collection promotion

Agreed, any proposal would come with an accompanying PR. Since the API itself is pretty straightforward, I don't think this will put any undue burden on the reviewers. Austin > On Jan 3, 2016, at 12:09 AM, Dave Abrahams wrote: > > >> On Jan 2, 2016, at 9:44 PM, Austin

Re: [swift-evolution] [swift-evolution-announce] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

Hi Drew, Thanks for the review, just a quick remark: “Real” type aliases are already forbidden inside protocols, so this proposal wouldn’t change that. (According to the grammar, a protocol body can only contain: property, method, initializer, subscript, or associated type member declarations)

Re: [swift-evolution] use standard syntax instead of "do" and "repeat"

> >> There are large classes of programs where you can know you don’t care >> exactly where a failure happens, e.g. (most init functions, all pure >> functions, any function that doesn’t break invariants). In these cases >> marking every statement or expression that can throw is just noise.

Re: [swift-evolution] [Proposal]: Free the '$' Symbol!

Well, that's just it. $ is a perfectly valid character in identifiers everywhere but in the grammar for operators for some reason. It isn't reserved, it just isn't there. ~Robert Widmann 2016/01/03 0:53、Brent Royal-Gordon のメッセージ: >> Swift currently does not allow

Re: [swift-evolution] [Proposal] Swift 2.2: #if swift language version

+1 from me as well, supporting conditional compilation when the two versions of foundation differ and may differ for the foreseeable future seems a must on this end. Sent from my iPhone > On 3 Jan 2016, at 10:12, Drew Crawford via swift-evolution > wrote: > >> If

Re: [swift-evolution] [Proposal] Swift 2.2: #if swift language version

> If we are going to support something like this, I’d rather see it be > something everyone could leverage as there are many use cases for this > feature: > > #if available("package-name", "1.2.*") > #endif Big +1. I've asked specifically to get some kind of conditional compilation on

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

> What are those advantages precisely? subjective: Easier to understand objective: Saves keywords/syntax ("…", "memberwise", "@nomemberwise", "required", "convenience", "@default"…) >> What I can see in your example is that the proposed syntax allows me to >> trigger compiler errors that

Re: [swift-evolution] [Pitch] Version-pinned patching of public declarations

Sorry if this should be clear already, but are you suggesting that @patch would allow patching of final or sealed types thus making them more palatable as defaults? This would surprise me, but if that is not what you are suggesting I don't follow how it relates to the final / sealed

Re: [swift-evolution] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

> * What is your evaluation of the proposal? +1, with caveats From a wording perspective, the “Proposed Approach” and “Impact on Existing Code” sections talk about removing typealias, while the intention is almost certainly to remove typealias usage within protocols only. My review

Re: [swift-evolution] Customized Inline Init Closure

Something similar has been discussed ("method cascading"), and I hope the feature will be considered for Swift 4(?). It is a little bit different, though: "self" would not change its meaning (which imho is a plus), and the syntax is different. Tino

Re: [swift-evolution] Inquiry: Status of SR-122 ?

Thanks for pointing me at it; at a quick read I like the functionality, but will have to take a closer look to get a sense of its feel in use. It certainly addresses the current gripes I have around `CollectionType` requiring a `ForwardIndexType`: for all but the truly-linear collections (e.g.,

Re: [swift-evolution] [swift-build-dev] [swiftpm] Add proposal for C language support

> On Jan 2, 2016, at 9:00 AM, Daniel Dunbar via swift-build-dev > wrote: > > Happy 2016! > > I am working on an initial proposal for adding support for C language targets > to the Swift package manager, and am interested in feedback: The idea of including C

Re: [swift-evolution] Asserts should not cause undefined behaviour

I gave a quick reply to an email later in the chain last night but I think these points are worth addressing. Apologies for the slow response, I wanted to ponder and consider the points rather than rush the response. >> On Dec 31, 2015, at 8:27 PM, Chris Lattner wrote: >>

Re: [swift-evolution] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

I like this. > On Jan 3, 2016, at 1:38 AM, Douglas Gregor via swift-evolution > wrote: > > Hello Swift community, > > The review of "Replace `typealias` keyword with `associatedtype` for > associated type declarations” begins now and runs through Wednesday, January

Re: [swift-evolution] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

+1 from me. It is a solid change that addresses an oddity in the language. On Sun, Jan 3, 2016 at 7:27 AM, plx via swift-evolution < swift-evolution@swift.org> wrote: > I like this. > > On Jan 3, 2016, at 1:38 AM, Douglas Gregor via swift-evolution < > swift-evolution@swift.org> wrote: > > Hello

Re: [swift-evolution] [swift-evolution-announce] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

> On 03 Jan 2016, at 07:38, Douglas Gregor wrote: > > * What is your evaluation of the proposal? I am in favor of this for the same reasons mentioned by the previous reviewers. > * Is the problem being addressed significant enough to warrant a change > to

[swift-evolution] [Proposal] Separate protocols and interfaces

Introduction of interfaces will clean up the current blend of static and dynamic protocols, and solve at least three popular issues. Please see: https://github.com/Anton3/swift-evolution/blob/master/proposals/-introducing-interfaces.md ___

Re: [swift-evolution] [swift-evolution-announce] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

> * What is your evaluation of the proposal? I think the proposal is great. The only thing I’d prefer is to use `associated` over `associatedtype`. `associated` has always felt better to me over `associatedtype`. It was mentioned in one of the original proposals as the keyword that was

Re: [swift-evolution] use standard syntax instead of "do" and "repeat"

> On Jan 2, 2016, at 2:23 PM, Tyler Cloutier wrote: > > Please see comments inline. > >> On Dec 31, 2015, at 12:07 PM, Dave Abrahams via swift-evolution >> wrote: >> >> On Dec 27, 2015, at 10:25 PM, Brent Royal-Gordon via

Re: [swift-evolution] use standard syntax instead of "do" and "repeat"

> On Jan 3, 2016, at 12:12 PM, Dave Abrahams via swift-evolution > wrote: > > >> On Jan 2, 2016, at 2:23 PM, Tyler Cloutier wrote: >> >> Please see comments inline. >> >>> On Dec 31, 2015, at 12:07 PM, Dave Abrahams via swift-evolution >>>

Re: [swift-evolution] [Proposal]: Free the '$' Symbol!

As I recall it, there is no overlap between operator characters and identifier characters. If it's not in the operator set, it's effectively reserved for identifiers. I also remember someone from Apple confirming what Brent said but I can't find it at the moment. Félix > Le 3 janv. 2016 à

Re: [swift-evolution] use standard syntax instead of "do" and "repeat"

In a block of code where errors are only thrown in some places, do+try is illustrative because it allows you to know which functions are possible failure points. However, in a block of code where errors are thrown in most places, a try block would be useful because individual try statements

Re: [swift-evolution] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

I'm not opposing the proposal, but I wonder why there has been such a big discussion (and a poll whose results have neither been revealed completely nor affected the choice of the keyword)… Swift has proven it can thrive in secrecy, so I don't think the whole open community is a necessity —

Re: [swift-evolution] use standard syntax instead of "do" and "repeat"

> On 3 Jan 2016, at 18:21, Matthew Johnson via swift-evolution > wrote: > > >> On Jan 3, 2016, at 12:12 PM, Dave Abrahams via swift-evolution >> wrote: >> >> >>> On Jan 2, 2016, at 2:23 PM, Tyler Cloutier

Re: [swift-evolution] [swift-evolution-announce] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

I have one concern with `associated` vs `associatedtype`, which is that it people might, in the interest of clarity, start naming things using a conventions like `associated PayloadType`, when I think it would be better to have `associatedtype Payload` because it leaves less room for

Re: [swift-evolution] use standard syntax instead of "do" and "repeat"

> On Jan 3, 2016, at 2:08 AM, Andrew Duncan via swift-evolution > wrote: > > >> >>> There are large classes of programs where you can know you don’t care >>> exactly where a failure happens, e.g. (most init functions, all pure >>> functions, any function that

Re: [swift-evolution] [Proposal] Separate protocols and interfaces

I like this, and had considered proposing something similar. Points: I would have chose to leave protocol to mean the dynamically dispatch-able type declaration, as that is what it indicates in Objective-C. Your proposal would cause every Objective-C protocol to now be considered an interface

Re: [swift-evolution] [swift-evolution-announce] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

Sorry for the previous message. I pressed “Send” by mistake... Here is my +1: > * What is your evaluation of the proposal? It’s a great improvement. > * Is the problem being addressed significant enough to warrant a change > to Swift? Definitely. > * Does this proposal fit

Re: [swift-evolution] use standard syntax instead of "do" and "repeat"

> On Jan 3, 2016, at 10:21 AM, Matthew Johnson wrote: > >> >> On Jan 3, 2016, at 12:12 PM, Dave Abrahams via swift-evolution >> wrote: >> >> >>> On Jan 2, 2016, at 2:23 PM, Tyler Cloutier wrote: >>> >>> Please see

Re: [swift-evolution] use standard syntax instead of "do" and "repeat"

> On Jan 3, 2016, at 10:51 AM, David Waite wrote: > > In a block of code where errors are only thrown in some places, do+try is > illustrative because it allows you to know which functions are possible > failure points. > > However, in a block of code where