# SE-0253: Static callables **URL:** \ **Category:** Proposal Reviews\ **Created:** [March 28, 2019, 12:25am UTC](https://forums.swift.org/t/se-0253-static-callables/22243 "2019-03-28T00:25:10Z")\ **Posts on this page:** 1\ **Showing post:** 32
**Author:** ![ben-cohen](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/ben-cohen/32/296_2.png) [@ben-cohen](https://forums.swift.org/u/ben-cohen)\ **Post date:** [April 2, 2019, 12:50am UTC](https://forums.swift.org/t/se-0253-static-callables/22243/32 "2019-04-02T00:50:14Z")
I think this proposal needs to go back for further thought rather than being accepted. I am concerned about accepting it for two reasons: it has a poor benefit to complexity ratio, and it should consider better integration with the existing functionality of closures. We've found ourselves considering a lot of sugar recently. Sugar is good! It makes the language nicer to use and is an important part of a balanced diet. But not all sugar is the same. Allowing key path expressions to be used as functions is a simple concept that seems unlikely to ever cause serious confusion, so is only a light dusting of cosmetic sugar. Return elision is not just sugar, it also makes the language more consistent by applying the same elision already allowed with closures. Property delegates are more heavyweight sugar, but that sugar is an important ingredient that will enable open up lots of new usage patterns. By contrast, this proposal introduces a reasonably significant language change, a new keyword, and a new term "callables" into our glossary, all for a really trivial payoff. It's nice to not have to write the `evaluate` in `polynomial.evaluate(2)`, for sure, but it's not exactly game changing. Unlike SE-0243, another-nice-to-have, I don't think it's nearly as obvious at the point of use what is happening. Others have mentioned a pretty big list of "how will this work?" unknowns that I won't repeat but that do worry me. Finally, I'm concerned that not enough consideration has gone into how this feature relates to closures. A proposal for callable should properly address closures being callables – to fully flesh out what this idea would mean and how it would work, what benefits it could bring, rather than just mention it as [an aside](https://github.com/apple/swift-evolution/blob/master/proposals/0253-callable.md#unifying-compound-types-and-nominal-types) in the proposal. --- _[View the full topic](https://forums.swift.org/t/se-0253-static-callables/22243)._