+1. It is very obscure that you can do this!<br><br>On Tuesday, 23 February 2016, Joe Groff via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><div style="word-wrap:break-word">Today, you can reference an instance property as a member of its type to access it as a fully unbound function, which is currently curried:<div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>struct Foo {</div><div>  var x: Int</div><div>  func foo(y y: Int) { return x + y }</div><div>}</div><div><br></div><div>let foo = Foo.foo</div><div>foo(Foo(x: 1))(y: 2) // returns 3</div><div><br></div></blockquote>However, this is problematic for `mutating` methods. Since the first argument is `inout`, the mutation window for the parameter formally ends before the second argument can be applied to complete the call. Currently we miscompile this, and form a closure over a dangling pointer, leading to undefined behavior:<div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>struct Bar {</div><div>  var x = 0</div><div>  mutating func bar() { x += 1 }</div><div>}</div><div><br></div><div>let bar = Bar.bar</div><div>var a = Bar()</div><div>bar(&amp;a)() // This might appear to work, if we don&#39;t optimize too hard</div><div><br></div><div>let closure: () -&gt; ()</div><div>do {</div><div>  var b = Bar()</div><div>  closure = bar(&amp;b)</div><div>}</div><div>closure() // This scribbles dead stack space</div><div><br></div><div>var c = Bar() {</div><div>  didSet { print(&quot;c was set&quot;) }</div><div>}</div><div><br></div><div>bar(&amp;c)() // This will scribble over c after didSet is called, if not worse</div><div><br></div></blockquote>We can close this hole by disallowing a reference to Bar.bar, like we already disallow partial applications. However, I think it would be in line with our other simplifications of the function type system to change the type of `Bar.bar` and other unapplied instance method references to no longer be curried. In addition to providing a model for unapplied instance methods that works with mutating methods, this would also eliminate a type difference between free functions and methods of the same arity, allowing for easier code reuse. For instance, `reduce` takes a closure of type (State, Element) -&gt; State. Flattening the formal type of instance methods would allow binary methods to be used as-is with `reduce`, like binary free functions can:<div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px">func sumOfInts(ints: [Int]) -&gt; Int { </blockquote><blockquote style="margin:0 0 0 40px;border:none;padding:0px">  return ints.reduce(0, combine: +)</blockquote><blockquote style="margin:0 0 0 40px;border:none;padding:0px">}</blockquote><blockquote style="margin:0 0 0 40px;border:none;padding:0px">func unionOfSets&lt;T&gt;(sets: [Set&lt;T&gt;]) -&gt; Set&lt;T&gt; { <br>  return ints.reduce([], combine: Set.union)<br>}</blockquote><div><br></div><div>What do you all think?</div><br><div>-Joe</div></div></div></div></div></blockquote><br><br>-- <br>-- Howard.<br>