<div dir="ltr">Hi Vladmir,<div><br></div><div>I read your thread earlier and thought you raised some really good points. Are you planning on preparing a proposal? If not, I'd be happy to fold your ideas in to make one big proposal. If you are already preparing one, you should just fold Doug's point into your proposal.</div><div><br></div><div>Best,</div><div>Austin</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 28, 2016 at 10:30 AM, Vladimir.S <span dir="ltr"><<a href="mailto:svabox@gmail.com" target="_blank">svabox@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 28.06.2016 19:49, Austin Zheng via swift-evolution wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This makes sense. If nobody objects I'll prepare a proposal today.<br>
</blockquote>
<br></span>
Austin, I'd ask to review this related(about function/closure type) thread<br>
in mailing list before preparing the proposal: "[Proposal] Disallow<span class=""><br>
implicit conversion between function/closure with a list of parameters and<br>
with tuple parameter. Remove function type inconsistency."<br>
<br></span>
I mean probably you'll want to form a more generic proposal to improve/make less surprising Swift's function types and add consistency in this area. I'd be happy if you'll add ideas from the thread mentioned above to your proposal.<div class="HOEnZb"><div class="h5"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
By the way, on the topic of design topics: is there any core team<br>
support for removing associated type inference? I have a proposal there<br>
that I would like to move into the formal review stage at some point.<br>
<br>
Best, Austin<br>
<br>
Sent from my iPhone<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Jun 28, 2016, at 9:33 AM, Douglas Gregor <<a href="mailto:dgregor@apple.com" target="_blank">dgregor@apple.com</a>><br>
wrote:<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Jun 27, 2016, at 10:40 PM, Charlie Monroe<br>
<<a href="mailto:charlie@charliemonroe.net" target="_blank">charlie@charliemonroe.net</a>> wrote:<br>
<br>
Oh, I see. The issue is then the following:<br>
<br>
let x = f x(1, 2) // Error: Missing argument labels 'a:b:' in call<br>
<br>
let y: (Int, Int) -> () = f f(1, 2) // OK<br>
<br>
Which requires you to write x(a: 1, b: 2). I must admit, however,<br>
that I always liked this behavior…<br>
</blockquote>
<br>
Right, that’s the issue. The idea behind this is that it’s a<br>
simplification to the type system to eliminate argument labels from<br>
types, so we can eliminate some extra subtyping relationships (e.g.,<br>
between function types with labels and ones without labels).<br>
Essentially, argument labels become part of the names of declarations<br>
(only!), which is consistent with our view that the names of<br>
functions/methods/initializers include all of the argument names.<br>
<br>
- Doug<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Jun 28, 2016, at 7:06 AM, Austin Zheng <<a href="mailto:austinzheng@gmail.com" target="_blank">austinzheng@gmail.com</a>><br>
wrote:<br>
<br>
I think the point is to get rid of the argument labels. 'x' should<br>
be typed simply (Int, Int) -> ().<br>
<br>
That being said, right now the argument labels in the type don't<br>
seem to actually affect anything, so like Chris I'm not sure what<br>
the counter-proposal is.<br>
<br>
(cc. Doug)<br>
<br>
Best, Austin<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Jun 27, 2016, at 10:04 PM, Charlie Monroe<br>
<<a href="mailto:charlie@charliemonroe.net" target="_blank">charlie@charliemonroe.net</a>> wrote:<br>
<br>
This came from a short list of topics Doug provided me, but<br>
the basic issue is that:<br>
<br>
func f(a : Int, b : Int) { let x = f // x has type (a: Int,<br>
b: Int) -> () }<br>
<br>
I’m not exactly sure what the counterproposal is.<br>
</blockquote>
<br>
My guess is to require let x = f(a:,b:) (specifying arguments)?<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
-Chris<br>
<br>
<br>
<br>
_______________________________________________<br>
swift-evolution mailing list <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote>
<br>
</blockquote>
<br>
</blockquote>
<br>
</blockquote>
<br>
</blockquote>
_______________________________________________ swift-evolution mailing<br>
list <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br>
</blockquote>
</div></div></blockquote></div><br></div>