<div dir="ltr">On Wed, Dec 16, 2015 at 11:34 AM, Matthew Johnson <span dir="ltr"><<a href="mailto:matthew@anandabits.com" target="_blank">matthew@anandabits.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div>This wouldn’t be ambiguous with static methods. Confusing to some developers possibly, but not ambiguous. Map would be expecting a function that takes an instance. Depending on the details of how it was defined in the language it could be ambiguous with a static property of a function type:</div></div></blockquote><div><br></div><div>Sorry, I meant ambiguous via extension (on a sequence type). Super contrived example:</div><div><br></div><div><div> struct Foo {</div><div> static var bar = Foo()</div><div> }</div><div> extension Array {</div><div> func map(foo: Foo) {}</div><div> }</div><div> [1, 2, 3].map(.bar)</div></div><div><br></div><div>I doubt there would be much ambiguity in practice, as disambiguation would come naturally at the call site.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div>There would not be an entirely new meaning for the . shorthand. It would be an extrapolation of the shorthand for enum cases.<br></div></div></blockquote><div><br></div><div>I merely meant that dot-abbreviation now specifically resolves to a static member that returns the type. The dot-abbreviation in your examples is a different behavior and adds a bit of complexity to learning Swift.</div><div><br></div><div>Stephen</div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 16, 2015 at 11:34 AM, Matthew Johnson <span dir="ltr"><<a href="mailto:matthew@anandabits.com" target="_blank">matthew@anandabits.com</a>></span> 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>This wouldn’t be ambiguous with static methods. Confusing to some developers possibly, but not ambiguous. Map would be expecting a function that takes an instance. Depending on the details of how it was defined in the language it could be ambiguous with a static property of a function type:</div><div><br></div><div>Car {</div><div> static let make: Car -> SomeOtherType</div><div>}</div><div><br></div><div>This potential ambiguity could probably be defined away by making the shorthand specifically apply to instance methods or something like that.</div><div><br></div><div>There would not be an entirely new meaning for the . shorthand. It would be an extrapolation of the shorthand for enum cases.</div><div><br></div><div>That said, I was replying quickly and my example was not quite accurate. “make" is a getter which cannot be accessed in unbound form today. There are proposals to allow this to be done in other threads. Syntax from one example is Car.make#get (lets not get caught up on syntax of that here). So correcting my example it would look like:</div><div><br></div><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div style="word-wrap:break-word"><div><div style="word-wrap:break-word"><div><span style="font-family:Menlo;font-size:11px;color:rgb(79,129,135)">cars</span><span style="font-family:Menlo;font-size:11px">.</span><span style="font-family:Menlo;font-size:11px;color:rgb(61,29,129)">map</span><span style="font-family:Menlo;font-size:11px">(.</span><span style="font-family:Menlo;font-size:11px;color:rgb(79,129,135)">make#get)</span></div></div></div></div></div></div></div></div><div><br></div><div>If make was a method we would need to bind all of the arguments except the curried instance argument so it would look like this:</div><div><br></div><div><span style="font-family:Menlo;font-size:11px;color:rgb(79,129,135)">cars</span><span style="font-family:Menlo;font-size:11px">.</span><span style="font-family:Menlo;font-size:11px;color:rgb(61,29,129)">map</span><span style="font-family:Menlo;font-size:11px">(.</span><span style="font-family:Menlo;font-size:11px;color:rgb(79,129,135)">make())</span></div><div><span style="font-family:Menlo;font-size:11px;color:rgb(79,129,135)"><br></span></div><div><span style="font-family:Menlo;font-size:11px;color:rgb(79,129,135)"><div style="color:rgb(0,0,0);font-family:Helvetica;font-size:12px">And a method with more arguments would look like this:</div><div style="color:rgb(0,0,0);font-family:Helvetica;font-size:12px"><br></div><div style="color:rgb(0,0,0);font-family:Helvetica;font-size:12px"><span style="font-family:Menlo;font-size:11px;color:rgb(79,129,135)">cars</span><span style="font-family:Menlo;font-size:11px">.</span><span style="font-family:Menlo;font-size:11px;color:rgb(61,29,129)">map</span><span style="font-family:Menlo;font-size:11px">(.</span><span style="font-family:Menlo;font-size:11px;color:rgb(79,129,135)">methodWithInt(1, string: “hello"))</span></div></span></div><div><br></div><div>I’m not necessarily advocating for something like this, just trying to think through the implications of it at this point.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Matthew</div></font></span><div><div class="h5"><br><div><blockquote type="cite"><div>On Dec 16, 2015, at 10:18 AM, Stephen Celis <<a href="mailto:stephen.celis@gmail.com" target="_blank">stephen.celis@gmail.com</a>> wrote:</div><br><div><div dir="ltr">On Wed, Dec 16, 2015 at 10:50 AM, Matthew Johnson via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div>If we peel off just the contextual shorthand aspect of this proposal you could write:</div><div><br></div><div><div style="word-wrap:break-word"><div><span style="font-family:Menlo;font-size:11px;color:rgb(79,129,135)">cars</span><span style="font-family:Menlo;font-size:11px">.</span><span style="font-family:Menlo;font-size:11px;color:rgb(61,29,129)">map</span><span style="font-family:Menlo;font-size:11px">(.</span><span style="font-family:Menlo;font-size:11px;color:rgb(79,129,135)">make)</span></div><div><br></div></div></div><div>That does seem like a big win if it is feasible (doesn’t introduce ambiguity or cause other significant challenges in implementation).</div></div></blockquote><div><br></div><div>The above creates ambiguity if there were a `map` function that takes a type with a static member `make`.</div><div><br></div><div>Alternatively:</div><div><br></div><div> cars.map{.make}</div><div><br></div><div>Both create an additional meaning for dot abbreviation, though, which is confusing. I think I'm "-1" on this proposal as is. The existing form is clearer and relatively short as is.<br></div><div><br></div><div>Stephen</div></div></div></div>
</div></blockquote></div><br></div></div></div></blockquote></div><br></div>