Re: [swift-evolution] [Proposal] Custom operators

Interesting model! If I understand correctly: this changes the precedence from being based on a numeric value, to being represented as a bit of a DAG of precedence groups. A precedence group is defined implicitly for each operator, with one group around each set of operators where equalTo has

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

> I'd prefer a more general solution instead of introducing the notion of an > "optional" function: just make it possible to write default implementations > inline in a protocol definition. This would work, too. I guess there's no need for an “optional” keyword if the implementation is right

Re: [swift-evolution] [Review] SE-0059: Update API Naming Guidelines and Rewrite Set APIs Accordingly

I think Michel and Shawn did raise some good points here. -Thorsten > Am 03.04.2016 um 22:27 schrieb Shawn Erickson via swift-evolution > : > >> On Sun, Apr 3, 2016 at 6:41 AM Michel Fortin via swift-evolution >> wrote: >> > What is your

Re: [swift-evolution] Proposal Discussion Thread: SwiftPM: Locking and Overriding Dependencies

> On Mar 21, 2016, at 4:05 PM, Max Howell wrote: > >> 2. I like VersionLocks.json well enough, but would like to see a discussion >> about possible alternatives. My personal proposal (in line with #1) is to >> use "PackageVersions.json" which has a nice agreement with

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

As the problem seems to be to eliminate having to write the extension with all its duplication, I'd prefer a more general solution instead of introducing the notion of an "optional" function: just make it possible to write default implementations inline in a protocol definition. Documenting

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

I understand the concern. To me, the answer is clearly yes. The language cannot be considered in isolation from its use cases; imagine UIKit written in Swift. You want the developers to be able to quickly understand which table view delegate methods they need to implement, and what the

Re: [swift-evolution] [Proposal] Custom operators

See inline > Am 03.04.2016 um 13:26 schrieb Ross O'Brien via swift-evolution > : > > There is a problem here of duplicated operators or custom precedence, and how > that gets passed between modules. > Assume there are three modules, A, B and C. B defines a custom

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

> On Apr 3, 2016, at 8:51 PM, David Waite via swift-evolution > wrote: > > Swift also has the benefit of built-in access to C/C++ and in some > environments Objective-C code and libraries. This means it does not have to > strive to either replace or to have

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

> On Apr 3, 2016, at 1:25 PM, John Heerema via swift-evolution > wrote: > So, I’d ask “why is it so terrible that we’re going to remove it, even though > it presents an obstacle to developers coming over to Swift?” Maybe there’s a > really good answer to that, but

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

For readability and specifically in this case, I think it does make sense IMHO. On Sunday, April 3, 2016, Chris Lattner wrote: > > On Apr 3, 2016, at 10:40 AM, Andrey Tarantsov > wrote: > >

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

> On Apr 3, 2016, at 10:40 AM, Andrey Tarantsov wrote: > >> Protocol requirements with default (no-op) implementations already satisfy >> that design goal, no? > > Chris, as we've discussed in a thread that I think got forked from this one: > > Yes, they do technically,

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0049 Move @noescape and @autoclosure to be type attributes

On Mon, Mar 28, 2016, at 09:48 AM, Douglas Gregor wrote: > Hello Swift community, > The review of SE-0049 "Move @noescape and @autoclosure to be type > attributes" begins now and runs through March 31, 2016. The proposal > is available here: I know the review period has elapsed, but the proposal

Re: [swift-evolution] [Review] SE-0059: Update API Naming Guidelines and Rewrite Set APIs Accordingly

On Sun, Apr 3, 2016 at 1:27 PM Shawn Erickson wrote: > On Sun, Apr 3, 2016 at 6:41 AM Michel Fortin via swift-evolution < > swift-evolution@swift.org> wrote: > >> > What is your evaluation of the proposal? >> >> I don't like "form" as a prefix. To me there is no difference

Re: [swift-evolution] [Review] SE-0059: Update API Naming Guidelines and Rewrite Set APIs Accordingly

On Sun, Apr 3, 2016 at 6:41 AM Michel Fortin via swift-evolution < swift-evolution@swift.org> wrote: > > What is your evaluation of the proposal? > > I don't like "form" as a prefix. To me there is no difference between > `union` and `formUnion`: both sounds functional-style, and actually the >

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

Thanks to all those who thoughtfully responded to this post! The folks who responded provided kind thoughts and advice. Ross O’Brian asked if I was familiar with the original discussion for 0004 and 0007. To answer: Yes, I read the discussions several times over a period of a few weeks before

Re: [swift-evolution] [Review] SE-0056: Allow trailing closures in `guard` conditions

One idea related to this `for...do` syntax--maybe this will satisfy some objections listed in the proposal: Currently, Swift has optional semicolons. In the same spirit, suppose control statements have optional colons, like this: `for eachValue in theValues: { code }`. All current syntax

Re: [swift-evolution] [Proposal] Custom operators

That doesn't sound future-proof. If it was in place and Range hadn't existed since the earliest Swift public release, it wouldn't be possible to define its precedence now. Félix > Le 3 avr. 2016 à 11:41:00, Ben Rimmington via swift-evolution > a écrit : > >

Re: [swift-evolution] [Proposal] Custom operators

Another way to eliminate numerical precedence is by using keywords: infix operator << { associativity none exponentiative } infix operator * { associativity left

Re: [swift-evolution] [Review] SE-0056: Allow trailing closures in `guard` conditions

Like others, I'm -1 on this due to added inconsistency between the guard and other control flow statements. R+ Sent from my iPhone > On 01 Apr 2016, at 05:27, Douglas Gregor via swift-evolution > wrote: > > Hello Swift community, > > The review of SE-0056 "Allow

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

> Protocol requirements with default (no-op) implementations already satisfy > that design goal, no? Chris, as we've discussed in a thread that I think got forked from this one: Yes, they do technically, but it would be nice to both: 1) make it an obvious documented part of the signature,

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

>> I've actually had multiple cases in Objective-C code where this feature >> (some object behaving differently depending on wether or not a delegate >> method has been implemented) has prevented me from implementing features the >> easy and obvious way. In those cases I resorted to

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

> I do not understand why an optional method should require a default value. > That’s not how optional methods work in Objective-C where the caller will ask > whether the method is implemented and calls it or does something else. With a > default value it would be much more difficult to do

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

> Some ideas I was thinking about for optional protocol functions was you’d > declare it like this: > > protocol UIGestureRecognizerDelegate { > optional func gestureRecognizerShouldBegin(gestureRecognizer: > UIGestureRecognizer) -> Bool = true > } > > If you put “optional” there, the

Re: [swift-evolution] Protected access level / multiple class/struct/protocol APIs

>> My point is that "protected" *isn't* access control. If we added it, it >> would have to be as an independent modifier. Private/internal/public >> fundamentally affect semantics—private and internal code is only accessible >> within a module, so we have full knowledge of their use sites at

Re: [swift-evolution] [Review] SE-0056: Allow trailing closures in `guard` conditions

> Le 2 avr. 2016 à 15:39, Patrick Gili via swift-evolution > a écrit : > >> What is your evaluation of the proposal? > I think there is a lot of value to allowing trailing closures in the guard > condition clause. However, not at the cost of inconsistency. We have

Re: [swift-evolution] [Review] SE-0056: Allow trailing closures in `guard` conditions

Although I use trailing closures a lot less now, I think I’m a +1 anyway for consistency’s sake. I actually really like the idea of having trailing keywords in loops and if statements, these needn’t be required (except where a trailing closure is used) but for example it means I could do a

Re: [swift-evolution] [Review] SE-0059: Update API Naming Guidelines and Rewrite Set APIs Accordingly

> What is your evaluation of the proposal? I don't like "form" as a prefix. To me there is no difference between `union` and `formUnion`: both sounds functional-style, and actually the second one perhaps a bit more to my ears. There's basically two dictionary definitions of "form": 1. "bring

Re: [swift-evolution] [Review] SE-0056: Allow trailing closures in `guard` conditions

Interesting idea to put keywords in the other statements so that they can also use trailing closures! On Sunday, 3 April 2016, Ilya Belenkiy via swift-evolution < swift-evolution@swift.org> wrote: > >- What is your evaluation of the proposal? > > +1. I stumble on this quite often. > > >-

Re: [swift-evolution] [Proposal] Custom operators

Right, the proposal in its current form does not really aim to resolve such conflicts, although it makes them occur less often by "merging" precedence and associativity when possible. At first, I also tried to resolve such conflicts by naming operators. But I found that compiler instructions will

Re: [swift-evolution] [Proposal] Custom operators

In these case of module operator conflicts perhaps there could be a way we could import these operators ? Likes a #importOperators(OtherModule) or some kind of build flag. *___* *James⎥Future Prime Minister* *ja...@supmenow.com ⎥supmenow.com

Re: [swift-evolution] [Proposal] Custom operators

There is a problem here of duplicated operators or custom precedence, and how that gets passed between modules. Assume there are three modules, A, B and C. B defines a custom operator **. A and C each define a custom operator ++, and their meanings are different (though, even if their meanings

Re: [swift-evolution] [Proposal] Custom operators

I think this is a great suggestion! One potential problem I can see (if I understood this correctly) is that modules are allowed to set up their own precedence rules for operators defined elsewhere. I think this might lead to some difficult to debug errors if a developer of one module (who is

Re: [swift-evolution] [Proposal] Custom operators

> On 3 Apr 2016, at 11:45, Антон Жилин wrote: > > > Assuming these are defined in separate modules, how do we determine the > > order of • and ~? > > By default, priority between any two operators is undefined. If two modules > don't know about each other, but the

Re: [swift-evolution] [Proposal] Custom operators

> Assuming these are defined in separate modules, how do we determine the order of • and ~? By default, priority between any two operators is undefined. If two modules don't know about each other, but the user wishes to prioritize them, then he will write: #precedence(•, lessThan: ~) If •

Re: [swift-evolution] [Proposal] Custom operators

Interesting, I like the idea of changing how precedence is defined, but I’m curious how under the new scheme we would go about inserting a new operator unambiguously? For example: #precedence(•, lessThan: *) #precedence(~, lessThan: *) Assuming these are defined in separate

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

It would be very interesting to see more examples dynamic loop conditions and dynamic loop increments using the Swifter for in loop with strides... without while :). [[iOS messageWithData:ideas] broadcast] > On 3 Apr 2016, at 09:19, Xiaodi Wu via swift-evolution >

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

On Sat, Apr 2, 2016 at 6:45 PM, John Heerema via swift-evolution wrote: > Yes, there are many cases in which I believe that Swift > provides looping structures that are safer and easier to understand than > the > C-style For loop. I¹d even say most cases. But I work in