<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title></title>
</head>
<body>
<div name="messageBodySection" style="font-size: 14px; font-family: -apple-system, BlinkMacSystemFont, sans-serif;">I'd be happy to see this enhancement as well.
<div><br /></div>
<div>For what it's worth, a real case that I've wanted to use this for is modifying named colors, as in:</div>
<div><br /></div>
<div>`view.backgroundColor = .blue.withAlphaComponent(0.5)`</div>
<div><br /></div>
<div>Not a major inconvenience for sure, but it would be nice if this worked.</div>
</div>
<div name="messageSignatureSection" style="font-size: 14px; font-family: -apple-system, BlinkMacSystemFont, sans-serif;"><br />
Jarod</div>
<div name="messageReplySection" style="font-size: 14px; font-family: -apple-system, BlinkMacSystemFont, sans-serif;"><br />
On Jun 29, 2017, 09:54 -0700, Joe Groff via swift-evolution <swift-evolution@swift.org>, wrote:<br />
<blockquote type="cite" style="margin: 5px 5px; padding-left: 10px; border-left: thin solid #1abc9c;"><br />
<blockquote type="cite" style="margin: 5px 5px; padding-left: 10px; border-left: thin solid #e67e22;">On Jun 29, 2017, at 5:19 AM, Matt Gallagher via swift-evolution <swift-evolution@swift.org> wrote:<br />
<br />
Super short summary:<br />
<br />
I think a function argument or right-hand-side expression prefixed with `.` should allow access to *any* static member on the expected type, dropping the existing limitations of this syntax.<br />
<br />
Detail:<br />
<br />
At the moment in Swift, you can use a `.` (period or dot) prefix to perform a scoped lookup of static vars and funcs on the expected type, if those static vars or funcs return that type.<br />
<br />
For example:<br />
<br />
// If we have a type `SomeNontrivialTypeName`<br />
struct SomeNontrivialTypeName {<br />
// With a static function returning `SomeNontrivialTypeName`<br />
static func a() -> SomeNontrivialTypeName<br />
}<br />
<br />
// And a function that requires a `SomeNontrivialTypeName` parameter<br />
func f(a: SomeNontrivialTypeName)<br />
<br />
// We can call the function like this:<br />
f(a: .a())<br />
<br />
The `.` prefix allows us to omit the typename `SomeNontrivialTypeName`; since the parameter already expects `SomeNontrivialTypeName`, the `.` already implies lookup in the list of static func/vars for `SomeNontrivialTypeName`.<br />
<br />
The purpose is syntactic efficiency and it's used to great extent across a wide range of Swift/AppKit/Foundation interfaces for enum-like value lookups. It lets us have very simple names that won't clash with names in the global namespace because they're not in the global namespace – and yet, they're only a single `.` more syntactic overhead.<br />
<br />
Unfortunately, there is no extendability. This approach will look up only static vars or funcs that immediately return the expected type and you can't transform the result – it's one function and done. For example, if `SomeNontrivialTypeName` has a fluent-style interface (i.e. an interface where instance methods return mutated `self` or new instances of `SomeNontrivialTypeName`):<br />
<br />
extension SomeNontrivialTypeName {<br />
func addThings() -> SomeNontrivialTypeName<br />
}<br />
<br />
trying to append this function won't work, even though the return type remains correct:<br />
<br />
f(a: .a().addThings())<br />
<br />
This fails and claims that we've forgotten to provide a parameter (!).<br />
<br />
A completely different kind of transformation might go via a different type<br />
<br />
extension SomeNontrivialTypeName {<br />
static func another() -> AnotherType<br />
}<br />
<br />
struct AnotherType {<br />
func back() -> SomeNontrivialTypeName<br />
}<br />
<br />
It would be nice to be able to use this "there-and-back-again" transformation:<br />
<br />
f(a: .another().back())<br />
<br />
But it also won't work.<br />
<br />
I realize that this is a point about minor syntactic efficiency. Yes, you could simply write:<br />
<br />
f(a: SomeNontrivialTypeName.another().back())<br />
<br />
but it's clunky and the type name gets in the way.<br />
<br />
There's also an element of consistency. Swift already lets us look up static functions in this way – but:<br />
<br />
* only functions that return the expected type<br />
* and we can't *use* the function result ourselves, it must be immediately yielded to the parameter or left-hand-side<br />
<br />
Seems more than a little strange.<br />
<br />
Anyone else care or have thoughts on this point?<br /></blockquote>
<br />
I've also wanted this. It seems like a straightforward extension of the existing feature, which already has to set up a constraint system dependent on the contextual type, but which happens to be artificially constrained to adding only one step of member lookup or of member lookup followed by a call of that member to the system.<br />
<br />
-Joe<br />
_______________________________________________<br />
swift-evolution mailing list<br />
swift-evolution@swift.org<br />
https://lists.swift.org/mailman/listinfo/swift-evolution<br /></blockquote>
</div>
</body>
</html>