<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">I personally use the existing behavior in some of my code, by providing the reference to the method directly to a method/function that takes a closure as a parameter. A modified excerpt from my code:</div><div class=""><br class=""></div><div class=""><font face="Courier New" class=""> let observer = <span class="">NSNotificationCenter</span><span class="">.defaultCenter().addObserverForName(LoginSuccess, object: </span><span class="">nil</span><span class="">, queue: </span><span class="">nil</span><span class="">, usingBlock: weakify(self, </span><span class="">self</span><span class="">.</span><span class="">dynamicType</span><span class="">.userDidLogin))</span></font></div><div class=""><span class=""><br class=""></span></div><div class="">(Note: This usage normally would lead to a retain cycle, but I wrap the method reference in this weakify() function which handles weakly applying self to the returned method reference.)</div><div class=""><br class=""></div><div class="">Un-currying method references would make this pattern harder to apply, so if there was a way to resolve this behavior without removing the current flexibility that the curried behavior offers, I would prefer that. Un-currying mutating methods only would be one option, but that seems a bit ugly. </div><div class=""><br class=""></div><div class="">However, if there isn't a way to fix it without changing existing behavior, I'd prefer the un-curried form everywhere to removing static method access outright.</div><div class=""><span class=""><br class=""></span></div><span class=""><div class="">Kevin Lundberg<br class=""><a href="mailto:kevin@klundberg.com" class="">kevin@klundberg.com</a><br class=""><br class=""><br class=""></div></span>
<br class=""><div><blockquote type="cite" class=""><div class="">On Feb 22, 2016, at 5:52 PM, Joe Groff via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">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 class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">struct Foo {</div><div class=""> var x: Int</div><div class=""> func foo(y y: Int) { return x + y }</div><div class="">}</div><div class=""><br class=""></div><div class="">let foo = Foo.foo</div><div class="">foo(Foo(x: 1))(y: 2) // returns 3</div><div class=""><br class=""></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 class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">struct Bar {</div><div class=""> var x = 0</div><div class=""> mutating func bar() { x += 1 }</div><div class="">}</div><div class=""><br class=""></div><div class="">let bar = Bar.bar</div><div class="">var a = Bar()</div><div class="">bar(&a)() // This might appear to work, if we don't optimize too hard</div><div class=""><br class=""></div><div class="">let closure: () -> ()</div><div class="">do {</div><div class=""> var b = Bar()</div><div class=""> closure = bar(&b)</div><div class="">}</div><div class="">closure() // This scribbles dead stack space</div><div class=""><br class=""></div><div class="">var c = Bar() {</div><div class=""> didSet { print("c was set") }</div><div class="">}</div><div class=""><br class=""></div><div class="">bar(&c)() // This will scribble over c after didSet is called, if not worse</div><div class=""><br class=""></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) -> 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 class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class="">func sumOfInts(ints: [Int]) -> Int { </blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""> return ints.reduce(0, combine: +)</blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class="">}</blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class="">func unionOfSets<T>(sets: [Set<T>]) -> Set<T> { <br class=""> return ints.reduce([], combine: Set.union)<br class="">}</blockquote><div class=""><br class=""></div><div class="">What do you all think?</div><br class=""><div class="">-Joe</div></div></div></div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>