Opt-out for first unnamed parameter instead of opt-in


(Vanderlei Martinelli) #1

Hello.

I think this was discussed before somewhere and I do not know what the
conclusion was, but since we have this in the documentation:

func addSubview(_ view: UIView)

And we have to write this:

func addSubview(view: UIView)

Why we can not stay with the first one that is more consistent? The impact
is to replace declarations like:

func myMethod(something something: AnyObject)

With

func myMethod(something: AnyObject)

And replace:

func myOtherMethod(something: AnyObject)

With

func myOtherMethod(_ somethings: AnyObject)


(Brent Royal-Gordon) #2

Why we can not stay with the first one that is more consistent? The impact is to replace declarations like:

func myMethod(something something: AnyObject)

With

func myMethod(something: AnyObject)

And replace:

func myOtherMethod(something: AnyObject)

With

func myOtherMethod(_ somethings: AnyObject)

An alternative might be to always require both names, but offer a shorthand for saying they're the same. Purely as an illustrative example, this would mess up syntax highlighting, but it follows an English punctuation usage:

  func myMethod(something ": AnyObject) // shorthand for `something something:`

This is perhaps a little more realistic, drawing on our convention of magic compiler substitution:

  func myMethod(something #: AnyObject) // shorthand for `something something:`

(Swift 1, of course, had `#something` for that, but dropped it, apparently because it was arbitrary and became rarely needed when methods and functions got the same parameter labeling rules in Swift 2. Neither of those would be the case now.)

In short, the whole "should we have default labels or not" question can simply go away forever for an extra two characters per parameter. That might be worth it.

···

--
Brent Royal-Gordon
Architechies


(Jessy) #3

How often do you find yourself wanting an internal parameter name, but not an external (case 4)? I think it’s very rare.

I doubt that the compiler’s AI will be able to deal with case 2.b, automatically, any time soon. That is okay with me, as long as we can manually type direct objects that would not be clear with only a preposition.

I think these represent the options for parameter names in order of prevalence. Case 3 has obviously never been available in Swift, but can be emulated with generic-sounding internal parameter names. If those types of names were not necessary, I believe all of these “opting” problems would go away. Is that incorrect?

1. Internal is the same as external
func function(int: Int) {}

2. External and internal names are different
a. func doThing(with int: Int) {}
b. func doThing(withGiraffe giraffe: Any) {}

3. No parameter name is needed internally or externally
func function(Int)

4. Underscore for external, name for internal
func function(_ int: Int) {}


(David Sweeris) #4

If we decide to allow external names without an internal name, I’m strongly in favor of the “func doThing(with _: Int) {}“ syntax. It makes it crystal clear that we’re purposefully not assigning an internal name to that argument.

- Dave Sweeris

···

On Feb 8, 2016, at 16:46, Jessy Catterwaul via swift-evolution <swift-evolution@swift.org> wrote:

Sorry, I forgot about this one:

5. An external, but not internal parameter name is needed. I don’t think a colon is useful in these cases.
func doThing(with Int) {}

It also could satisfy a protocol requirement, without having to resort to this kind of underscore usage, which should become illegal:
func doThing(with _: Int) {}

On Feb 8, 2016, at 5:32 PM, Jessy Catterwaul <mr.jessy@gmail.com <mailto:mr.jessy@gmail.com>> wrote:

How often do you find yourself wanting an internal parameter name, but not an external (case 4)? I think it’s very rare.

I doubt that the compiler’s AI will be able to deal with case 2.b, automatically, any time soon. That is okay with me, as long as we can manually type direct objects that would not be clear with only a preposition.

I think these represent the options for parameter names in order of prevalence. Case 3 has obviously never been available in Swift, but can be emulated with generic-sounding internal parameter names. If those types of names were not necessary, I believe all of these “opting” problems would go away. Is that incorrect?

1. Internal is the same as external
func function(int: Int) {}

2. External and internal names are different
a. func doThing(with int: Int) {}
b. func doThing(withGiraffe giraffe: Any) {}

3. No parameter name is needed internally or externally
func function(Int)

4. Underscore for external, name for internal
func function(_ int: Int) {}

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Jordan Rose) #5

Among other things, this allows a warning or style check equivalent to Clang's -Wunused-param. You could always give the parameter a dummy name and then assign it to _, but this makes the intent clearer, IMHO, that the parameter is ignored.

On the other hand, it also destroys any way of referring to it in a doc comment, so if you want to say why it's ignored you're in trouble.

Jordan

···

On Feb 8, 2016, at 18:08, Dave via swift-evolution <swift-evolution@swift.org> wrote:

If we decide to allow external names without an internal name, I’m strongly in favor of the “func doThing(with _: Int) {}“ syntax. It makes it crystal clear that we’re purposefully not assigning an internal name to that argument.

- Dave Sweeris

On Feb 8, 2016, at 16:46, Jessy Catterwaul via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Sorry, I forgot about this one:

5. An external, but not internal parameter name is needed. I don’t think a colon is useful in these cases.
func doThing(with Int) {}

It also could satisfy a protocol requirement, without having to resort to this kind of underscore usage, which should become illegal:
func doThing(with _: Int) {}

On Feb 8, 2016, at 5:32 PM, Jessy Catterwaul <mr.jessy@gmail.com <mailto:mr.jessy@gmail.com>> wrote:

How often do you find yourself wanting an internal parameter name, but not an external (case 4)? I think it’s very rare.

I doubt that the compiler’s AI will be able to deal with case 2.b, automatically, any time soon. That is okay with me, as long as we can manually type direct objects that would not be clear with only a preposition.

I think these represent the options for parameter names in order of prevalence. Case 3 has obviously never been available in Swift, but can be emulated with generic-sounding internal parameter names. If those types of names were not necessary, I believe all of these “opting” problems would go away. Is that incorrect?

1. Internal is the same as external
func function(int: Int) {}

2. External and internal names are different
a. func doThing(with int: Int) {}
b. func doThing(withGiraffe giraffe: Any) {}

3. No parameter name is needed internally or externally
func function(Int)

4. Underscore for external, name for internal
func function(_ int: Int) {}

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Jessy) #6

Sorry, I forgot about this one:

5. An external, but not internal parameter name is needed. I don’t think a colon is useful in these cases.
func doThing(with Int) {}

It also could satisfy a protocol requirement, without having to resort to this kind of underscore usage, which should become illegal:
func doThing(with _: Int) {}

···

On Feb 8, 2016, at 5:32 PM, Jessy Catterwaul <mr.jessy@gmail.com> wrote:

How often do you find yourself wanting an internal parameter name, but not an external (case 4)? I think it’s very rare.

I doubt that the compiler’s AI will be able to deal with case 2.b, automatically, any time soon. That is okay with me, as long as we can manually type direct objects that would not be clear with only a preposition.

I think these represent the options for parameter names in order of prevalence. Case 3 has obviously never been available in Swift, but can be emulated with generic-sounding internal parameter names. If those types of names were not necessary, I believe all of these “opting” problems would go away. Is that incorrect?

1. Internal is the same as external
func function(int: Int) {}

2. External and internal names are different
a. func doThing(with int: Int) {}
b. func doThing(withGiraffe giraffe: Any) {}

3. No parameter name is needed internally or externally
func function(Int)

4. Underscore for external, name for internal
func function(_ int: Int) {}


(Vanderlei Martinelli) #7

The “send” button was pressed before I finish the message, I’m sorry.

Continuing:

With

func myOtherMethod(_ something: AnyObject)

Regards,

-Van

···

On Mon, Feb 8, 2016 at 7:54 PM, Vanderlei Martinelli < vmartinelli@alecrim.com> wrote:

Hello.

I think this was discussed before somewhere and I do not know what the
conclusion was, but since we have this in the documentation:

func addSubview(_ view: UIView)

And we have to write this:

func addSubview(view: UIView)

Why we can not stay with the first one that is more consistent? The impact
is to replace declarations like:

func myMethod(something something: AnyObject)

With

func myMethod(something: AnyObject)

And replace:

func myOtherMethod(something: AnyObject)

With

func myOtherMethod(_ somethings: AnyObject)


(Dave Abrahams) #8

Just a note on terminology: we're trying to standardize on the terms
“parameter name” and “argument label”:

           func f(argumentLabel parameterName: ParameterType)

           f(argumentLabel: argument)

···

on Mon Feb 08 2016, Dave <swift-evolution@swift.org> wrote:

If we decide to allow external names without an internal name, I’m
strongly in favor of the “func doThing(with _: Int) {}“ syntax. It
makes it crystal clear that we’re purposefully not assigning an
internal name to that argument.

- Dave Sweeris

On Feb 8, 2016, at 16:46, Jessy Catterwaul via swift-evolution >> <swift-evolution@swift.org> wrote:

Sorry, I forgot about this one:

5. An external, but not internal parameter name is needed. I don’t
think a colon is useful in these cases.
func doThing(with Int) {}

It also could satisfy a protocol requirement, without having to
resort to this kind of underscore usage, which should become
illegal:
func doThing(with _: Int) {}

On Feb 8, 2016, at 5:32 PM, Jessy Catterwaul >>> <mr.jessy@gmail.com >>> <mailto:mr.jessy@gmail.com>> wrote:

How often do you find yourself wanting an internal parameter name,
but not an external (case 4)? I think it’s very rare.

I doubt that the compiler’s AI will be able to deal with case 2.b,
automatically, any time soon. That is okay with me, as long as we
can manually type direct objects that would not be clear with only
a preposition.

I think these represent the options for parameter names in order of
prevalence. Case 3 has obviously never been available in Swift, but
can be emulated with generic-sounding internal parameter names. If
those types of names were not necessary, I believe all of these
“opting” problems would go away. Is that incorrect?

1. Internal is the same as external
func function(int: Int) {}

2. External and internal names are different
a. func doThing(with int: Int) {}
b. func doThing(withGiraffe giraffe: Any) {}

3. No parameter name is needed internally or externally
func function(Int)

4. Underscore for external, name for internal
func function(_ int: Int) {}

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
-Dave


(Jessy) #9

I relent. It would be more clear, as with closures, if we are forced to use _, when we don’t use $0.

To reiterate, external names without internal names do currently compile, and probably compile for this use case:

protocol Protocol {
   func doThing(with nameNotEnforced: Int)
}

struct Satisfier: Protocol {
   func doThing(with _: Int) {}
}

That’s different than what doesn’t yet compile, but ought to, to account for nondescript parameters.

protocol Protocol {
   func printGoat(@autoclosure while () -> Bool)
}

struct Implementer: Protocol {
   func printGoat(@autoclosure while () -> Bool) {
      // $0 must be used in this function
      while $0() {print("Goat")}
   }
}

Implementer().printGoat(while: swimmingInMoat)

···

On Feb 8, 2016, at 9:08 PM, davesweeris@mac.com wrote:

If we decide to allow external names without an internal name, I’m strongly in favor of the “func doThing(with _: Int) {}“ syntax. It makes it crystal clear that we’re purposefully not assigning an internal name to that argument.

- Dave Sweeris

On Feb 8, 2016, at 16:46, Jessy Catterwaul via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Sorry, I forgot about this one:

5. An external, but not internal parameter name is needed. I don’t think a colon is useful in these cases.
func doThing(with Int) {}

It also could satisfy a protocol requirement, without having to resort to this kind of underscore usage, which should become illegal:
func doThing(with _: Int) {}

On Feb 8, 2016, at 5:32 PM, Jessy Catterwaul <mr.jessy@gmail.com <mailto:mr.jessy@gmail.com>> wrote:

How often do you find yourself wanting an internal parameter name, but not an external (case 4)? I think it’s very rare.

I doubt that the compiler’s AI will be able to deal with case 2.b, automatically, any time soon. That is okay with me, as long as we can manually type direct objects that would not be clear with only a preposition.

I think these represent the options for parameter names in order of prevalence. Case 3 has obviously never been available in Swift, but can be emulated with generic-sounding internal parameter names. If those types of names were not necessary, I believe all of these “opting” problems would go away. Is that incorrect?

1. Internal is the same as external
func function(int: Int) {}

2. External and internal names are different
a. func doThing(with int: Int) {}
b. func doThing(withGiraffe giraffe: Any) {}

3. No parameter name is needed internally or externally
func function(Int)

4. Underscore for external, name for internal
func function(_ int: Int) {}

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(Chris Lattner) #10

I agree that we should have this discussion, but I think it is imperative that we wait until the naming discussion settles down. Any decision on the language behavior here will be necessarily shaped by how that works out.

-Chris

···

On Feb 8, 2016, at 1:54 PM, Vanderlei Martinelli via swift-evolution <swift-evolution@swift.org> wrote:

Hello.

I think this was discussed before somewhere and I do not know what the conclusion was, but since we have this in the documentation:


(Jessy) #11

I think that’s pretty good. Except, what is it known as when they are one and the same? "Pargumenter name"?

···

On Feb 8, 2016, at 11:47 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

Just a note on terminology: we're trying to standardize on the terms
“parameter name” and “argument label”:

          func f(argumentLabel parameterName: ParameterType)

          f(argumentLabel: argument)


(Howard Lovatt) #12

+1 from me. As an aside: there is a lot of discussion about this sort of
thing in the API guideline threads.

···

On Tuesday, 9 February 2016, Vanderlei Martinelli via swift-evolution < swift-evolution@swift.org> wrote:

The “send” button was pressed before I finish the message, I’m sorry.

Continuing:

With

func myOtherMethod(_ something: AnyObject)

Regards,

-Van

On Mon, Feb 8, 2016 at 7:54 PM, Vanderlei Martinelli < > vmartinelli@alecrim.com > <javascript:_e(%7B%7D,'cvml','vmartinelli@alecrim.com');>> wrote:

Hello.

I think this was discussed before somewhere and I do not know what the
conclusion was, but since we have this in the documentation:

func addSubview(_ view: UIView)

And we have to write this:

func addSubview(view: UIView)

Why we can not stay with the first one that is more consistent? The
impact is to replace declarations like:

func myMethod(something something: AnyObject)

With

func myMethod(something: AnyObject)

And replace:

func myOtherMethod(something: AnyObject)

With

func myOtherMethod(_ somethings: AnyObject)

--
  -- Howard.