<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 25, 2016, at 9:13 AM, Joe Groff <<a href="mailto:jgroff@apple.com" class="">jgroff@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Feb 24, 2016, at 8:50 PM, Chris Lattner <<a href="mailto:clattner@apple.com" class="">clattner@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">None of these are really great. Since you’re advocating for it, I’m very concerned about making partially applied methods be uncurried always (#2). I have seen a *lot* of people use curried methods on classes (in particular) and this leads to some pretty elegant patterns. I’d expect any serious discussion of changing this behavior to include a survey of what people are actually using this for, and whether the end result we’d get from this change would be better or worse overall (not just in a single case).</span></div></blockquote></div><br class=""><div class="">I'm concerned about that too, but I think most of these use cases are already impeded by removing tuple argument splatting, since that makes it impossible to make a generic method transformation like `alterMethod<Receiver, Args, Ret>(method: Receiver -> Args -> Ret)`. I think these use cases can be recovered on flattened methods by explicit variadic splatting, since you could then write `alterMethod<Receiver, Args, Ret>(method: (Receiver, Args...) -> Ret)` instead.</div></div></div></blockquote><br class=""></div><div>I don’t really understand that, because the use-cases I’ve seen aren’t in generic context’s, but let me step back and see if I understand your proposal. Here’s your example again:</div><div><br class=""></div><div><div class=""><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><blockquote class="" style="margin: 0px 0px 0px 40px; border: none; padding: 0px;"><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 a = Bar.bar</div></blockquote></div></div></div></div></div></blockquote></div><div class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><blockquote class="" style="margin: 0px 0px 0px 40px; border: none; padding: 0px;"><div class=""><br class=""></div></blockquote></div></div></div></div></div></div></div>I believe that you’re proposing that “a” have type "(inout Bar) -> ()” since the empty argument list got flattened into the self argument.<div class=""><br class=""></div><div class="">However, what is the type of the partial application case, i.e. “someBarInstance.bar”?<div class=""><br class=""></div><div class="">It seems that this *has* to be invalid for mutating methods, and it is the most commonly curried forms that I’ve seen for classes.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">I would be extremely nervous about saying that partial application and the raw name disagree, and I really wouldn’t want to kill partial application for classes and non-mutating methods.</div><div class=""><br class=""></div><div class="">I think that the least bad answer here is to just have sema reject attempts to get the base name of the mutating methods. In fact, my memory was partially right. We *are* already rejecting the partial application case:</div><div class=""><br class=""></div><div class=""><div style="margin: 0px; font-size: 10px; line-height: normal; font-family: Monaco;" class=""><span style="font-variant-ligatures: no-common-ligatures; color: #a9a9a9" class=""> 5> </span>var b = Bar()</div><div style="margin: 0px; font-size: 10px; line-height: normal; font-family: Monaco; color: rgb(52, 187, 199);" class="">b: Bar = {</div><div style="margin: 0px; font-size: 10px; line-height: normal; font-family: Monaco; color: rgb(52, 187, 199);" class=""> x = 0</div><div style="margin: 0px; font-size: 10px; line-height: normal; font-family: Monaco; color: rgb(52, 187, 199);" class="">}</div><div style="margin: 0px; font-size: 10px; line-height: normal; font-family: Monaco;" class=""><span style="font-variant-ligatures: no-common-ligatures; color: #a9a9a9" class=""> 6> </span>b.bar</div><div style="margin: 0px; font-size: 10px; line-height: normal; font-family: Monaco;" class="">repl.swift:6:3: <span style="font-variant-ligatures: no-common-ligatures; color: #c33720" class="">error: </span>partial application of 'mutating' method is not allowed</div><div style="margin: 0px; font-size: 10px; line-height: normal; font-family: Monaco;" class=""><br class=""></div></div><div class="">so I think that we are just missing a simple case that we should be rejecting here.</div><div class=""><br class=""></div><div class="">-Chris</div><div class=""><div class=""><br class=""></div><div class=""><br class=""></div></div></div></body></html>