Compound variable names

Sure, I’m not trying to propose actionable concrete alternatives here—just expressing a preference for us to use the key path syntax under discussion for compound-name members and bound methods if it turns out to be in conflict with the unbound/uncurried method usage.

And I’m expressing a preference for having a clear path forward for access to unbound, uncurried methods regardless of what happens with this proposal. I think the proposal will be stronger if it addresses this point.

1 Like

I'm a little confused as to what you're looking for in this "clear path forward." As far as I'm aware, the design space for the syntax these unbound, uncurried method references is basically wide open—the key-path-based '\.f(x:)' syntax is one suggested option, but there's no reason that it couldn't be, say, #unboundUncurried(S.f(x:)), or an unbounded number of alternatives.

It seems out-of-scope for this proposal to explore the design space of a largely unrelated feature that simply happens to share a tentative syntax for one aspect. Especially so when, IMO, the only reasonable way to form a key path to a compound name is as \.f(x:). I don't see the alternatives of "you can't form a key path to a member with a compound name" and "key paths which refer to a compound name use a different syntax than 'normal' members" as tenable options.

I'd be happy to add a paragraph to the KeyPath and compound names section that mentions this potential overlap/conflict, but if you could provide some more concrete suggestions about how you'd like to see this consideration addressed in the proposal I'm all ears!

A more broad thought that I'm interested in the community's feedback on: is there any reason why changing a declaration from

func foo(x: Int) {}

to

let foo(x:): (Int) -> Void = {}

should not be an API-compatible change? I can't think of any off the top of my head. Should such a change be ABI-compatible?

"may" or "must"?

This seems to conflict with the later statement "Compound names are not permitted to appear in any position which would result in them being the external label to a function parameter."

I don't believe it is either of these in general, nor can be. The simplest demonstration I can think of is:

struct S {
    let foo: (Int) -> Void
}

let offset = MemoryLayout<S>.offset(of: \S.foo)  // Okay

versus

struct S {
    func foo(_ : Int) {}
}

let offset = MemoryLayout<S>.offset(of: \S.foo)  // Nonsense

I think the same would be true of a class type.

I think "may" is appropriate, since you could also call the variable by referencing the name and immediately applying it, as you can do with methods/functions today:

f(x1:...xn:)(arg1, ..., argn)

Good catch! I had thought that the parameter production was defined as

parameter → external-parameter-name local-parameter-name_opt type-annotation

but turns out it's

parameter → external-parameter-name_opt local-parameter-name type-annotation

so we can exclude the compound name from the external name from the external name in the grammar. Nice!

Even simpler, this proposal promises key paths to members with compound names which don't exist at all for methods (yet...). I think we could (?) promise that the method -> compound member transformation is API-compatible, though I don't know if its worth it to make that a guarantee (even if it ends up being the case in practice).

I wonder—does any promise like that exist today for turning func foo() {} into var foo: () -> Void?

I would like to have an understanding of whether this feature would in fact conflict with use of this syntax for unbound, uncurried methods or not. Hopefully someone from the core team can chime in and the answer can be included in the proposal text for reviewers to consider when evaluating this proposal.

1 Like

FWIW, regardless of this proposal we'd have to have some way to deal with the fact that \Foo.bar may refer to the bar member of an instance with type Foo, or the unbound, uncurried method bar of type Foo—however that gets resolved ShouldTM be able to extend to compound names as well.

Terms of Service

Privacy Policy

Cookie Policy