> On Dec 28, 2015, at 1:14 PM, Joe Groff <[email protected]> wrote:
>> On Dec 28, 2015, at 1:09 PM, Brent Royal-Gordon <[email protected]>
>> 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.
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
