[swift-evolution] [Proposal draft] Generalized Naming for Any Function

[John McCall]

> On Dec 28, 2015, at 1:14 PM, Joe Groff <jgroff at apple.com> wrote:
>> On Dec 28, 2015, at 1:09 PM, Brent Royal-Gordon <brent at architechies.com> wrote:
>> 
>>> and you could access the unapplied lens for an instance property using `Type.property` syntax, analogous to how `Type.method` works. I feel like if we did that, then it would obviate the need for explicit `property.get` or `property.set` for most native Swift uses, though maybe not ObjC interop uses.
>> 
>> I feel like if you don't have a way to fetch an unbound getter, you're missing the 90% case, which is constructs like:
>> 
>> 	let textValues = textViews.map(.#text.get)
> 
> Agreed. I think there are a couple ways to approach that. We could resolve unbound property references contextually, so that Type.property gives you the getter in normal function context, or the lens in inout function context, and/or either allow implicit upconversion from lens to getter function or provide an explicit getter((inout T) -> inout U) -> T -> U adapter function.

So the contextual lookup rule would be:

If the expression
  .foo
or
  .foo(E…)
is known from context to yield a value of type T, then:
  if T is a nominal type, the expression is equivalent to T.foo(E…);
  if T is a function type (inout? U -> V), then the expression is equivalent to { (x: inout? U) in x.foo(E…) };
  if T is a lens function type (inout? U -> inout V), then the argument expression (E…) shall not be present and the expression shall be equivalent to { (x: inout? U) in &x.foo }, or whatever the “applied” lens syntax is;
otherwise the expression is ill-formed.

This would be an obstacle to allowing extension methods on a hypothetical Swift.Function<X,Y> type, but I think that’s an acceptable sacrifice.

John.