I agree that the compiler can change, of course ;)
But I see a problem with this particular change, because the current usage of the implicit member expression is unambiguous: it must be the member of the type required by the context, that is, either a static function/property that returns an instance of that type, or an enum case constructor, which is the basically the same thing as the first option. I currently don't think that changing this behavior is desirable.
But I agree that there are greater concerns about the pitch.
I guess it could, but it would have a different meaning than the current implicit member expression, and I don't think it's a good idea.
For example, if in magical future swift functions become nominal types, and we'll be able to add members to them (this is something that a huge chunk of the community wants to happen), that syntax would be ambiguous.
(Int) -> Foo was typealiased, like the following:
typealias FooProvider = (Int) -> Foo let myCase: FooProvider = .bar
I would expect
.bar to be something that returns a
FooProvider, and that I can call on
That's what makes keypaths great! And I think their usefulness is probably something that was glimpsed only by those that tried to use keypath and experiment with them in generic algorithms. I have spoken with a number of swift users that don't use keypaths at all, mostly because they don't understand them or know their existence, and that's fine: it's part of the "progressive disclosure" that makes the language great for newcomers. I think there's also plenty of users that don't understand what enums with associated types are for.
But, as this doesn't undermine the fact that enums are the correct way to represent a data structure with alternative options, keypaths are the correct way to represent the "connection" between a data structure and its members, at any level of nesting.
I think the point here is that you could use any function where you need an instance of
(Int) -> Foo, not just