On Nov 11, 2017, at 6:52 PM, Matthew Johnson <matt...@anandabits.com> wrote:
>>>> In point of fact, Swift already has the feature you are referring to. It
>>>> just spells it with square brackets instead of parentheses. A simple
>>>> change to the punctuation character has much less point than the proposal
>>>> that I’m pitching.
>>>
>>> This is true if you squint, but I imagine a design for callable types would
>>> include some
>>> differences other than just punctuation.
>
> I think there was a pretty good discussion of this distinction in the
> SE-0021 timeframe. Specifically, subscripts model storage while callable
> would model functions. This means that subscripts can be used in a key path
> while callable would not (at last for now).
Sure, subscript getters are more general than calls in that respect, I agree.
> On the other hand, I would want to see callables implicitly convert to a
> value of a compatible function type (possibly through a subtype relationship).
Subscripts are generalizations of the property model in Swift. We’ve discussed
being able to curry the getter of a property, so I don’t see why currying the
getter of a subscript should work any different. This would directly provide
the functionality you’re referring to.
> Without this capability the syntactic illusion is only half complete. The
> callable feels like a function when used directly but not when it is assigned
> to a function type or passed elsewhere - it must be explicitly be wrapped in
> a closure and the arguments forwarded. First-class callable types are a
> syntactic sugar feature and as such if they exist they should be usable
> syntactically in all of the same ways functions are.
>
> Read-only subscripts are ok as a workaround in absence of first-class
> callable types (although I think in many ways just using `call` is better).
> Nevertheless, they are a workaround and can never be more than that because
> of the fundamental difference in what they model.
Please don’t misunderstand me. I’m not saying that:
let a = x[foo: 42, “bonk”, bar: 17]
is “better” than:
let a = x(foo: 42, “bonk”, bar: 17)
when x is a functor or something else function like. Syntax matters: it is the
principle way that language communicates to programmers, and sending an
indexing connotation is very different than sending a call connotation. My
point is simply that we already have the ability to *express* this concept, so
users have a way to solve a problem (even in a suboptimal way).
In contrast, we do not have a way to express the dynamically callable form,
which is the subject of my proposal. The workaround is not a change of one
punctuation character to another, it is a significantly heavier syntactic form
like x.call(…) or perhaps Joe’s proposal of introducing weird punctuation.
In any case, as I have reiterated many times, I simply want to solve the Python
import problem. I am not wed to this approach. If there is another approach
that provides a equal (or better) result, then I’m super interested to hear
about it. The only alternative that I’m aware of is to burn support for Python
into the Swift compiler, which I’m pretty opposed to doing: not only is it
significantly more complexity than the proposals required to implement this in
libraries, it also signs us up to do the same for Perl, Ruby, Javascript, …...
-Chris
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
