Re: [swift-evolution] [Pitch] Allow trailing argument labels

-1 to this proposal. While it is true that adding the argument labels helps you "read" it better, you end up with an inverted binary operator. I'll call it a sandwich. Argument labels should be used to name an argument so the fact that there is no argument provided means that this is not a good

Re: [swift-evolution] [Pitch] Allow trailing argument labels

> On 25 Feb 2017, at 01:25, Robert Bennett via swift-evolution > wrote: > >> Sorry, that turned into a bit of a rant, though hopefully a constructive >> one. I wasn't directing this at you in particular; I just wanted to properly >> get those points across. > > No

Re: [swift-evolution] [Pitch] Allow trailing argument labels

> Sorry, that turned into a bit of a rant, though hopefully a constructive one. > I wasn't directing this at you in particular; I just wanted to properly get > those points across. No worries at all, we're all working towards the same goal here. While I agree that the current proposals feel

[swift-evolution] [Pitch] Allow trailing argument labels

Sorry, that turned into a bit of a rant, though hopefully a constructive one. I wasn't directing this at you in particular; I just wanted to properly get those points across. Begin Message Group: gmane.comp.lang.swift.evolution MsgID:

[swift-evolution] [Pitch] Allow trailing argument labels

Hi everyone, this is my first post, hopefully I get the formatting and everything right... > why not just require a leading dot, like an enum, rather than a colon? > less syntax to learn, and it still eliminates the extra type. I think this could lead to ambiguity if the trailing argument label

Re: [swift-evolution] [Pitch] Allow trailing argument labels

On 23.02.2017 17:35, Haravikk wrote: On 23 Feb 2017, at 12:49, Vladimir.S > wrote: On 23.02.2017 14:17, Haravikk wrote: On 22 Feb 2017, at 21:25, Patrick Pijnappel

Re: [swift-evolution] [Pitch] Allow trailing argument labels

> On 23 Feb 2017, at 18:25, Vladimir.S wrote: > Weird idea, why not have function name just after arguments block, without > any separator: > > func adding(_ other:Self) -> Self > func adding(_ other:Self)reportingOverflow -> (Self, Bool) > > let resultOnly = a.adding(b) >

Re: [swift-evolution] [Pitch] Allow trailing argument labels

> On 23 Feb 2017, at 12:49, Vladimir.S wrote: > > On 23.02.2017 14:17, Haravikk wrote: >> >>> On 22 Feb 2017, at 21:25, Patrick Pijnappel >> > wrote: >>> >>> To summarize, there's one ambiguous case we'd need to

Re: [swift-evolution] [Pitch] Allow trailing argument labels

On 23.02.2017 14:17, Haravikk wrote: On 22 Feb 2017, at 21:25, Patrick Pijnappel > wrote: To summarize, there's one ambiguous case we'd need to resolve: func foo(_ x: Int, reportingOverflow) func foo(_ x: Int, _

Re: [swift-evolution] [Pitch] Allow trailing argument labels

why not just require a leading dot, like an enum, rather than a colon? less syntax to learn, and it still eliminates the extra type. Begin Message Group: gmane.comp.lang.swift.evolution MsgID: >On 22 Feb 2017, at

Re: [swift-evolution] [Pitch] Allow trailing argument labels

> On 22 Feb 2017, at 21:25, Patrick Pijnappel > wrote: > > To summarize, there's one ambiguous case we'd need to resolve: > > func foo(_ x: Int, reportingOverflow) > func foo(_ x: Int, _ reportingOverflow: Bool) > > let reportingOverflow = true > foo(5,

Re: [swift-evolution] [Pitch] Allow trailing argument labels

To summarize, there's one ambiguous case we'd need to resolve: func foo(_ x: Int, reportingOverflow) func foo(_ x: Int, _ reportingOverflow: Bool) let reportingOverflow = true foo(5, reportingOverflow) // Ambiguous One solution is to make trailing argument labels syntactic sugar for a trailing

Re: [swift-evolution] [Pitch] Allow trailing argument labels

On 22.02.2017 22:47, Haravikk wrote: On 22 Feb 2017, at 15:38, Vladimir.S > wrote: Do I understand correctly, that the proposed solution is some kind of sugar to not have separate method named like 'addingWithReportingOverflow' ? Basically yes; the

Re: [swift-evolution] [Pitch] Allow trailing argument labels

> On 22 Feb 2017, at 15:38, Vladimir.S wrote: > Do I understand correctly, that the proposed solution is some kind of sugar > to not have separate method named like 'addingWithReportingOverflow' ? Basically yes; the discussion came up briefly during protocol oriented integers

Re: [swift-evolution] [Pitch] Allow trailing argument labels

> On 22 Feb 2017, at 15:38, Vladimir.S > wrote: > Do I understand correctly, that the proposed solution is some kind of sugar > to not have separate method named like 'addingWithReportingOverflow' ? Basically yes; the discussion came up briefly

Re: [swift-evolution] [Pitch] Allow trailing argument labels

On 22.02.2017 17:22, Haravikk via swift-evolution wrote: On 22 Feb 2017, at 13:19, Derrick Ho > wrote: I've read the pitch, but it isn't clear what the ask is or what benefit it would give. The purpose of the feature is to enable selection of

Re: [swift-evolution] [Pitch] Allow trailing argument labels

> On 22 Feb 2017, at 13:19, Derrick Ho wrote: > > I've read the pitch, but it isn't clear what the ask is or what benefit it > would give. The purpose of the feature is to enable selection of identically named methods with similar signatures. This came up in the

Re: [swift-evolution] [Pitch] Allow trailing argument labels

I've read the pitch, but it isn't clear what the ask is or what benefit it would give. On Wed, Feb 22, 2017 at 8:05 AM Haravikk via swift-evolution < swift-evolution@swift.org> wrote: > > On 22 Feb 2017, at 11:48, Brent Royal-Gordon > wrote: > > On Feb 22, 2017, at 3:32

Re: [swift-evolution] [Pitch] Allow trailing argument labels

> On 22 Feb 2017, at 11:48, Brent Royal-Gordon wrote: > >> On Feb 22, 2017, at 3:32 AM, Haravikk via swift-evolution >> wrote: >> >> foo.example(foo) // What did I mean here? >> let result = foo.example(foo:) // This looks like I

Re: [swift-evolution] [Pitch] Allow trailing argument labels

> On Feb 22, 2017, at 3:32 AM, Haravikk via swift-evolution > wrote: > > foo.example(foo) // What did I mean here? > let result = foo.example(foo:) // This looks like I might be trying to > select a function, rather than call it I think it would be

Re: [swift-evolution] [Pitch] Allow trailing argument labels

> On 22 Feb 2017, at 10:24, Patrick Pijnappel via swift-evolution > wrote: > > I'd like to discuss allowing a trailing 'argument label' without an actual > argument: > > func adding(_ other: Self, reportingOverflow) -> … // Actual case in SE-104 > where this came

Re: [swift-evolution] [Pitch] Allow trailing argument labels

+1 I've encountered this issue myself on several occasions, and I think you'd always be able to create a function signature that reads like a proper sentence if this is implemented. On Wed, Feb 22, 2017 at 9:24 PM, Patrick Pijnappel via swift-evolution < swift-evolution@swift.org> wrote: > I'd

Re: [swift-evolution] [Pitch] Allow trailing argument labels

I'd like to see this, particularly in initialisers. Objective C can have '- (instanceType) init' and '- (instanceType) initWithQualifier', where Swift can only have 'init()'. On Wed, Feb 22, 2017 at 10:24 AM, Patrick Pijnappel via swift-evolution < swift-evolution@swift.org> wrote: > I'd like to

[swift-evolution] [Pitch] Allow trailing argument labels

I'd like to discuss allowing a trailing 'argument label' without an actual argument: func adding(_ other: Self, reportingOverflow) -> … // Actual case in SE-104 where this came up func tableView(_ tableView: UITableView, numberOfSections) -> Int // Referenced as tableView(_:numberOfSections) As