[swift-evolution] Utilizing arguments without meaningful internal names

[Jessy Catterwaul]

Sometimes they matter. Sometimes they don’t. You must believe in the former idea, or not be using Swift, but regardless of if you believe in the latter, the example that I showed compiles. Perhaps it only exists now for protocol conformance? I see it as a good place to start getting shorthand argument names integrated outside of closures.

I’ll chime back in when I find a good case, in production, for using external but not internal names. Most of the times that names don’t matter is in generic operator signatures. 

e.g. Here’s an operator I use (I saw something very similar recently called “then”).

/// Useful for initializing something and doing 
/// things with it immediately thereafter.
///
///- Returns: `$0`
///
/// Example:
///```
/// var instance = Type()…{
///    $0.property = newValue
///    $0.doSomething()
/// }
///```
///- Remark: Hold option, press ;
public func …<Type>(
   _$0: Type,
   @noescape ƒ0: Type -> ()
) -> Type {
   ƒ0(_$0)
   return _$0
}

In the future, I’d prefer to keep the documentation the same, but have the code be this:

public let …<Type>(Type, @noescape Type -> ()) {
   ƒ0(.0)
   return .0
}

1. The distinction between immutable closures and functions should dissolve, hence “let" 
2. Trailing closures should be known by default as ƒ0, ƒ1, etc.
3. $ is ugly and should be changed to .
4. Return type should be implicit


> On Feb 4, 2016, at 3:26 AM, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
> on Wed Feb 03 2016, Jessy Catterwaul <swift-evolution at swift.org> wrote:
> 
>> I’ve found that good external parameter names are typically just prepositions. 
>> 
>> Sometimes the noun that comes after the prepositions doesn’t benefit
>> from a real name. I’ve been naming those _$0 to minimize cognitive
>> load. (I don’t think about the name when writing, and when reading, I
>> know that the name would be useless to commit to my short-term
>> memory.)
>> 
>> func move<Point>(to _$0: Point) {
>>   // argument is accessible as _$0
>> }
> 
> Try to write a documentation comment summary for this without mentioning
> _$0.  The parameter names actually matter.
> 
>> Currently, this also compiles:
>> 
>> func move<Point>(to _: Point) {
>>   // argument is inaccessible
>> }
>> 
>> Is that useless? I think it’s useless but I might be missing something.
>> 
>> I propose that, when external parameter names are used, but internal
>> ones use underscores, the arguments are accessible as $0, $1, etc. (I
>> use $0 a lot, and $1 a little, but have not yet needed $2,
>> personally.)
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> -- 
> -Dave
> 
> _______________________________________________
> swift-evolution mailing list
> 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/20160204/63013013/attachment.html>