Utilizing arguments without meaningful internal names


(Jessy) #1

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
}

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.)


(Dave Abrahams) #2

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.

···

on Wed Feb 03 2016, Jessy Catterwaul <swift-evolution@swift.org> wrote:

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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
-Dave


(Jessy) #3

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@swift.org> wrote:

on Wed Feb 03 2016, Jessy Catterwaul <swift-evolution@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
-Dave

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


(Brent Royal-Gordon) #4

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

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
}

Both of these examples seem strictly less readable than this:

  public func … <Value>(value: Value, accessor: @noescape Value -> ()) -> Value {
    accessor(value)
    return value
  }

They're shorter, but brevity is not a virtue if it makes your code less clear. Swift is not APL.

1. The distinction between immutable closures and functions should dissolve, hence “let"

How do you handle overloading? `let` shadows, while `func` overloads.

Also, what is actually gained by eliminating the keyword marking functions as different from constants?

2. Trailing closures should be known by default as ƒ0, ƒ1, etc.

So, how many people know how to type ƒ? I sure don't.

3. $ is ugly and should be changed to .

Which already has a different meaning, looking up a static property or method on the contextually expected type.

4. Return type should be implicit

Eliminating the one rock—function signatures—that Swift's type inference system, which already can easily get into serious computational complexity, has to cling to.

···

--
Brent Royal-Gordon
Architechies


(Jessy) #5

How do you handle overloading? `let` shadows, while `func` overloads.

It does now, but closures can’t currently be overloaded, which doesn’t make sense. You can’t store two overloads in closures that have the same names as those functions. This must end at some point.

Also, what is actually gained by eliminating the keyword marking functions as different from constants?

Simplicity. Having both functions and closures in the language is complexity. I doubt it’s needed but haven’t heard otherwise.
https://forums.developer.apple.com/thread/16594

So, how many people know how to type ƒ? I sure don’t.

There aren’t that many keys on a keyboard and only using them leads to nonsense like $0. Hold option and type F. It’s easier to learn than making any Swift compile.

3. $ is ugly and should be changed to .

Which already has a different meaning, looking up a static property or method on the contextually expected type.

No, you can’t have a static property named with a number.


#6

How do you handle overloading? `let` shadows, while `func` overloads.

It does now, but closures can’t currently be overloaded, which doesn’t make sense. You can’t store two overloads in closures that have the same names as those functions. This must end at some point.

Also, what is actually gained by eliminating the keyword marking functions as different from constants?

Simplicity. Having both functions and closures in the language is complexity. I doubt it’s needed but haven’t heard otherwise.
https://forums.developer.apple.com/thread/16594

So, how many people know how to type ƒ? I sure don’t.

There aren’t that many keys on a keyboard and only using them leads to nonsense like $0. Hold option and type F. It’s easier to learn than making any Swift compile.

And where does one find the option key on standard PC running Linux or Windows (when using for example the IBM Swift Sandbox). It have been a few time I see people suggest using some fancy unicode character easily accessible on my preferred device keyboard but which are nearly impossible to type on typical no Apple devices. Call me old fashion but the standard keywords and symbols provided by the language should be limited to plain ASCII which can be used from any standard QWERTY keyboard without any fancy Apple-ism. I know not everyone use QWERTY; And from limited experience (I switch the mapping on the first swear), I know that it’s a pain to write code on a keyboard like French-Canadian, on which I can never find those dreadful curly-braces or even the slash. I do not want to bring this pain with me (and to others) when playing with Swift on a non-Apple device.

Sorry for the ranting,
Dany

···

Le 5 févr. 2016 à 20:18, Jessy Catterwaul via swift-evolution <swift-evolution@swift.org> a écrit :

3. $ is ugly and should be changed to .

Which already has a different meaning, looking up a static property or method on the contextually expected type.

No, you can’t have a static property named with a number.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Jordan Rose) #7

Let's make sure we keep the conversation polite and respectful. I don't think any lines have been crossed yet but I can hear the voices rising. Let's keep it :-).

Jordan

···

On Feb 5, 2016, at 17:58, Dany St-Amant via swift-evolution <swift-evolution@swift.org> wrote:

Le 5 févr. 2016 à 20:18, Jessy Catterwaul via swift-evolution <swift-evolution@swift.org> a écrit :

How do you handle overloading? `let` shadows, while `func` overloads.

It does now, but closures can’t currently be overloaded, which doesn’t make sense. You can’t store two overloads in closures that have the same names as those functions. This must end at some point.

Also, what is actually gained by eliminating the keyword marking functions as different from constants?

Simplicity. Having both functions and closures in the language is complexity. I doubt it’s needed but haven’t heard otherwise.
https://forums.developer.apple.com/thread/16594

So, how many people know how to type ƒ? I sure don’t.

There aren’t that many keys on a keyboard and only using them leads to nonsense like $0. Hold option and type F. It’s easier to learn than making any Swift compile.

And where does one find the option key on standard PC running Linux or Windows (when using for example the IBM Swift Sandbox). It have been a few time I see people suggest using some fancy unicode character easily accessible on my preferred device keyboard but which are nearly impossible to type on typical no Apple devices. Call me old fashion but the standard keywords and symbols provided by the language should be limited to plain ASCII which can be used from any standard QWERTY keyboard without any fancy Apple-ism. I know not everyone use QWERTY; And from limited experience (I switch the mapping on the first swear), I know that it’s a pain to write code on a keyboard like French-Canadian, on which I can never find those dreadful curly-braces or even the slash. I do not want to bring this pain with me (and to others) when playing with Swift on a non-Apple device.

Sorry for the ranting,
Dany


#8

Words can be seen as harsher that they were meant to be, as information is lost when converting thoughts to words, translating some of them to English, and removing the movement of the hands and the expression on the face. I see that my first sentence could be read back as some kind of aggressive barking back, but it was not. It was more a "did you think of" with an edge (not sure of the proper that)

Dany

···

Le 5 févr. 2016 à 21:10, Jordan Rose <jordan_rose@apple.com> a écrit :

On Feb 5, 2016, at 17:58, Dany St-Amant via swift-evolution <swift-evolution@swift.org> wrote:

Le 5 févr. 2016 à 20:18, Jessy Catterwaul via swift-evolution <swift-evolution@swift.org> a écrit :

How do you handle overloading? `let` shadows, while `func` overloads.

It does now, but closures can’t currently be overloaded, which doesn’t make sense. You can’t store two overloads in closures that have the same names as those functions. This must end at some point.

Also, what is actually gained by eliminating the keyword marking functions as different from constants?

Simplicity. Having both functions and closures in the language is complexity. I doubt it’s needed but haven’t heard otherwise.
https://forums.developer.apple.com/thread/16594

So, how many people know how to type ƒ? I sure don’t.

There aren’t that many keys on a keyboard and only using them leads to nonsense like $0. Hold option and type F. It’s easier to learn than making any Swift compile.

And where does one find the option key on standard PC running Linux or Windows (when using for example the IBM Swift Sandbox). It have been a few time I see people suggest using some fancy unicode character easily accessible on my preferred device keyboard but which are nearly impossible to type on typical no Apple devices. Call me old fashion but the standard keywords and symbols provided by the language should be limited to plain ASCII which can be used from any standard QWERTY keyboard without any fancy Apple-ism. I know not everyone use QWERTY; And from limited experience (I switch the mapping on the first swear), I know that it’s a pain to write code on a keyboard like French-Canadian, on which I can never find those dreadful curly-braces or even the slash. I do not want to bring this pain with me (and to others) when playing with Swift on a non-Apple device.

Sorry for the ranting,
Dany

Let's make sure we keep the conversation polite and respectful. I don't think any lines have been crossed yet but I can hear the voices rising. Let's keep it :-).

Jordan