[swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

[Chris Lattner]

On Nov 10, 2017, at 6:05 PM, Slava Pestov via swift-evolution <swift-evolution at swift.org> wrote:
>> On Nov 10, 2017, at 6:01 PM, Chris Lattner <sabre at nondot.org> wrote:
>> 
>> It is.  It is strictly sugar, as mentioned in the proposal.
> 
> All new code has a cost.

Indeed, I’m quite aware of that!

>> I do not expect any SIL or IRGen changes associated with this proposal, just type checker changes.  The type checker changes should be straight-forward, but you can evaluate that when there is a patch.
> 
> Like I said, the type checker’s code for solving member constraints and applying the solution is already a rats-nest of special cases to deal with the rich semantics of method calls in Swift. We’ve been trying to simplify it over time and fix bugs, and adding new special cases is a step in the wrong direction.

A strict interpretation of your paragraph above says that no new thing should ever be added to the language, which I am sure is not what  you mean.

That said, I understand what you’re concerned with.  However, your approach with this pitch has been completely unconstructive and unhelpful.  There is a time and place where evaluation of the impact can take place: that’s when the patch is available.  You are correct that all extensions come at a cost, which is why the cost and the *benefit* have to be weighed.

>> Our goal is for Swift to be awesome, not comparable to “other statically typed languages”.
> 
> Ok, but being awesome is not the same as adding every possible feature to the language.

I’m scratching my head and wondering if you seriously believe that you’re informing something that isn’t obvious.

>> swift-evolution isn’t about priorities.  I’m not asking someone else to implement this, and you don’t tell me how I spend my engineering time :-) :-)
> 
> Again, my point here is that implementing a new feature is just the first step. New code also has to be maintained going forward.

Again, I’m pretty aware of how long term software projects works.

>> I’m open to requiring these to be the same type if there is a benefit to doing so. What benefit do you see?
> 
> Can you think of a case where they have to be different?

Yes, it is easy to imagine cases where the parameters are all that matters.  In that case the result would be Void.

-Chris