[Revision] SE-0253: Introduce callables.

[rxwei]

Implementation: swiftlang/swift#24299

[lattner]

The proposal looks pretty good. In addition to the comments I mentioned above, the proposal should mention that the x.call syntax can be used to refer to the callable in a partially applied way, and this syntax aligns with the Type.init syntax.

[lattner]

The proposal name is very generic, and Swift already has callable things. How about "User Defined Callable Types"?

[rxwei]

I'm intentionally avoiding "callable types" because 1. func call is not restricted to primary type declarations and there's no type declaration attributes, and 2. types being callable sound like initializers.

[rxwei]

I changed the title to "User-defined callable values". What do you think?

[lattner]

Isn't fp a user defined callable value?

var fp : () -> () = {}

[rxwei]

That's a good point. How about "non-function callable values"?

[lattner]

Metatypes.

Why not call this "Allowing user defined types to be callable"?

[rxwei]

Metatypes are not callable today actually, though I understand in the implementation they are.

let x = Float.self
x(2)

error: repl.swift:2:2: error: initializing from a metatype value must reference 'init' explicitly
x(2)
 ^
 .init

[rxwei]

I changed it to "Callable values of user-defined nominal types" to be a bit more accurate. Hope that sounds okay to you!

[lattner]

A few other observations:

• I'd recommend saying something about how simple and non-invasive the implementation is.

• "Implicit conversions to function" should mention that you can already explicitly convert them through partial application.

• I don't think that "static/class call methods" are a likely future direction personally, for exactly the reasons you say. Why not drop that or move to alternatives considered?

• The first entry of 'alternatives considered' should be other names for this, including "call" "invoke" "apply" or other things that will come up in the thread.

[rxwei]

• I'd recommend saying something about how simple and non-invasive the implementation is.

Mentioned in the "detailed design" section.

• "Implicit conversions to function" should mention that you can already explicitly convert them through partial application.

Done.

• I don't think that "static/class call methods" are a likely future direction personally, for exactly the reasons you say. Why not drop that or move to alternatives considered?

Moved to "alternatives considered".

• The first entry of 'alternatives considered' should be other names for this, including "call" "invoke" "apply" or other things that will come up in the thread.

Done.