[swift-evolution] Opt-out for first unnamed parameter instead of opt-in

[Jessy Catterwaul]

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 at 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 at swift.org <mailto:swift-evolution at 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 at gmail.com <mailto:mr.jessy at 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 at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160208/9f9268ad/attachment.html>