Can't declare variable with same name as func called to assign its initial value

Adopting the newer Swift style of preferring first parameter labels, I wrote a function:

    func sale(options options: DeepLinkOptions)
        throws
        -> Sale
    {
        // ...implementation...
    }

I then tried calling it elsewhere, and setting the result to a variable named 'sale', which is coincidentally the same name as the function above:

    let sale = try sale(options: options)

This line won't compile, failing with the following error and a caret pointing at the second use of 'sale':

    variable used within its own initial value

In the past, I would've named the function above according to Objective-C conventions, and it might've ended up with a name like 'saleWithOptions'; there'd be no clash. However, with the more terse Swift 3.0 style, we'll probably end up with more situations like mine.

Is this (should this be?) considered a bug or compiler limitation? Should I file a JIRA? There doesn't seem to be anything for this on bugs.swift.org yet.

I'm going to go with the classic answer: Urban Dictionary: Henny Youngman problem

consider: let sale2 = sale
you could then run sale2(options: options)

So why should let sale = sale be any different?

···

On May 12, 2016, at 1:07 PM, Evan Maloney via swift-users <swift-users@swift.org> wrote:

Adopting the newer Swift style of preferring first parameter labels, I wrote a function:

   func sale(options options: DeepLinkOptions)
       throws
       -> Sale
   {
       // ...implementation...
   }

I then tried calling it elsewhere, and setting the result to a variable named 'sale', which is coincidentally the same name as the function above:

   let sale = try sale(options: options)

This line won't compile, failing with the following error and a caret pointing at the second use of 'sale':

   variable used within its own initial value

In the past, I would've named the function above according to Objective-C conventions, and it might've ended up with a name like 'saleWithOptions'; there'd be no clash. However, with the more terse Swift 3.0 style, we'll probably end up with more situations like mine.

Is this (should this be?) considered a bug or compiler limitation? Should I file a JIRA? There doesn't seem to be anything for this on bugs.swift.org yet.

I can't recall whether functions and variables can have the same name (though I think not), but at the least that error message seems to miss the point.

···

Sent from my iPhone

On May 12, 2016, at 14:07, Evan Maloney via swift-users <swift-users@swift.org> wrote:

Adopting the newer Swift style of preferring first parameter labels, I wrote a function:

   func sale(options options: DeepLinkOptions)
       throws
       -> Sale
   {
       // ...implementation...
   }

I then tried calling it elsewhere, and setting the result to a variable named 'sale', which is coincidentally the same name as the function above:

   let sale = try sale(options: options)

This line won't compile, failing with the following error and a caret pointing at the second use of 'sale':

   variable used within its own initial value

In the past, I would've named the function above according to Objective-C conventions, and it might've ended up with a name like 'saleWithOptions'; there'd be no clash. However, with the more terse Swift 3.0 style, we'll probably end up with more situations like mine.

Is this (should this be?) considered a bug or compiler limitation? Should I file a JIRA? There doesn't seem to be anything for this on bugs.swift.org yet.
_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

I'm going to go with the classic answer: http://www.urbandictionary.com/define.php?term=Henny+Youngman+problem <Urban Dictionary: Henny Youngman problem;

consider: let sale2 = sale
you could then run sale2(options: options)

So why should let sale = sale be any different?

Shouldn't the use of the 'options' parameter label result in the function name not clashing with the generic 'sale'?

In the case of the error line itself, I would've assumed from the context that the compiler would know that I wanted to invoke the function named 'sale' rather than refer to the function in the abstract. The passing of the parameter value should be enough of a tip-off about that, no?

And from that line on within the local scope, I'd understand if a local variable named 'sale' shadowed a no-arg function also named 'sale', but given that this function is really named 'sale(options:)', I would've thought this'd work.

···

On May 12, 2016, at 3:12 PM, Erica Sadun <erica@ericasadun.com> wrote:

On May 12, 2016, at 1:07 PM, Evan Maloney via swift-users <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:

Adopting the newer Swift style of preferring first parameter labels, I wrote a function:

   func sale(options options: DeepLinkOptions)
       throws
       -> Sale
   {
       // ...implementation...
   }

I then tried calling it elsewhere, and setting the result to a variable named 'sale', which is coincidentally the same name as the function above:

   let sale = try sale(options: options)

This line won't compile, failing with the following error and a caret pointing at the second use of 'sale':

   variable used within its own initial value

In the past, I would've named the function above according to Objective-C conventions, and it might've ended up with a name like 'saleWithOptions'; there'd be no clash. However, with the more terse Swift 3.0 style, we'll probably end up with more situations like mine.

Is this (should this be?) considered a bug or compiler limitation? Should I file a JIRA? There doesn't seem to be anything for this on bugs.swift.org <Issues · apple/swift · GitHub; yet.

I'm going to go with the classic answer: http://www.urbandictionary.com/define.php?term=Henny+Youngman+problem <Urban Dictionary: Henny Youngman problem;

consider: let sale2 = sale
you could then run sale2(options: options)

So why should let sale = sale be any different?