You're surprised a relatively easy to implement, one off feature with no dependencies and no impact on the rest of the language can be done before a feature that impacts huge areas of the language and requires underlying runtime and compiler support?

It's easy enough to say things like "well if you don't like it don't use it". Meanwhile as a primarily swift dev I can't stop others (outside of my team) from using this disastrous syntax.

The first time I have to dig into someone's backwards codebase that uses I'm gonna flip.

Objects defining named functions allows you to reason about them logically. Car.tireSizeInches() returns an Int type. Any other developer can see that and know whats up, or type "Car." and explore relevant functionality. What the crap does Car() do? Etc.

This is a huge backwards step for swift syntax. I hope most of the large open source libs ban it.

As for implementation difficulty, see my sibling reply.

Well callAsFunction is extremely simple to implement and test. Where as async/await is a much bigger and more complex feature. It's not amazing, it's totally logical.

I understand the difference in difficulty, my point is any incremental time spent on this is wasted and could have contributed towards something else that's useful.

That's not how software development works.

If I've got a new team member, I'm not going to put him on async/await. I'm going to find him something simpler to work on.

Or maybe I've been working on a feature for a few months and I need a break to clear my head so I'll work on a smaller feature for a while.

Software development isn't just assembling widgets on an assembly line. It's a creative process. Developers aren't chained to their desks pumping out a non-descript streams of "code" that become different features. Likely incremental time spent on this had almost no real impact on more difficult and useful features.

> I'm going to find him something simpler to work on.

Sure, but why should this non-feature which makes code harder to read and reason about even be built in the first place? All to save `.parse` at the call site of a parser, for example?

This syntax already exists in the language. If you want users to be able to use the obj() syntax you can already give them a closure for obj. Allowing it for user-defined types too removes an artificial syntactic distinction.

Async/await might actually help you clean up your codebase. Much better to have more syntactical sugar to keep code reviews lively and add more surprises for future developers!