<div dir="ltr">Apologies for the accidentally sent email.  Not sure what GMail just did for me there.  Anyways, with a macro it should be possible to use the types given to choose between mangled names, for example, at compile time.<div>
<br></div><div>Kevin</div><div><div><div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jun 6, 2014 at 2:44 AM, Kevin Cantu <span dir="ltr"><<a href="mailto:me@kevincantu.org" target="_blank">me@kevincantu.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I imagine a macro like the following, which is NOT a macro, because I don't know how to write macros yet:<div>
<br></div><div><br></div><div>macro fillRect(args...) {</div><div class=""><div><br></div><div><div style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:13px">
fillRect_RF_B ( const QRectF & rectangle, const QBrush & brush )</div><div style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:13px">fillRect_I_I_I_I_BS ( int x, int y, int width, int height, Qt::BrushStyle style )</div>

<div style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:13px">fillRect_Q_BS ( const QRect & rectangle, Qt::BrushStyle style )</div><div style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:13px">

fillRect_RF_BS ( const QRectF & rectangle, Qt::BrushStyle style )</div><div style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:13px">fillRect_R_B ( const QRect & rectangle, const QBrush & brush )</div>

<div style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:13px">fillRect_R_C ( const QRect & rectangle, const QColor & color )</div><div style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:13px">

fillRect_RF_C ( const QRectF & rectangle, const QColor & color )</div><div style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:13px">fillRect_I_I_I_I_B ( int x, int y, int width, int height, const QBrush & brush )</div>

<div style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:13px">fillRect_I_I_I_I_C ( int x, int y, int width, int height, const QColor & color )</div><div style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:13px">

fillRect_I_I_I_I_GC ( int x, int y, int width, int height, Qt::GlobalColor color )</div><div style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:13px">fillRect_R_GC ( const QRect & rectangle, Qt::GlobalColor color )</div>

<div style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:13px">fillRect_RF_GC ( const QRectF & rectangle, Qt::GlobalColor color )</div></div><div><br></div><div><br></div><div><br></div><div><br></div><div>

<br></div><div><br></div></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jun 6, 2014 at 2:35 AM, Kevin Cantu <span dir="ltr"><<a href="mailto:me@kevincantu.org" target="_blank">me@kevincantu.org</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Since C# allows overloaded methods, but F# doesn't want them, what F# does is somewhat interesting: "overloaded methods are permitted in the language, provided that the arguments are in tuple form, not curried form." [<a href="http://msdn.microsoft.com/en-us/library/dd483468.aspx" target="_blank">http://msdn.microsoft.com/en-us/library/dd483468.aspx</a>]</div>


<div><br></div><div>In practice, this means that all the calls to C# (tupled arguments) can be resolved, but idiomatic F# doesn't have overloaded methods.</div><div><br></div><div>// tuple calling convention: looks like C#</div>


<div>let aa = <a href="http://csharp_library.mx" target="_blank">csharp_library.mx</a>(1, 2)</div><div>let bb = <a href="http://csharp_library.mx" target="_blank">csharp_library.mx</a>(1)</div><div><br></div><div>// curried calling convention: makes dd, below, a function not a value</div>


<div>let cc = fsharp_library.m2 1 2</div><div>let dd = fsharp_library.m2 1</div><div><br></div><div>Would it be useful to use pattern matching over some generic sort of tuples to implement something similar in Rust?</div>

<span><font color="#888888">
<div><br></div><div><br></div><div>Kevin</div><div><br></div></font></span></div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, May 24, 2014 at 3:45 AM, Matthieu Monrocq <span dir="ltr"><<a href="mailto:matthieu.monrocq@gmail.com" target="_blank">matthieu.monrocq@gmail.com</a>></span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote"><div>On Sat, May 24, 2014 at 9:06 AM, Zoltán Tóth <span dir="ltr"><<a href="mailto:zo1980@gmail.com" target="_blank">zo1980@gmail.com</a>></span> wrote:<br>



<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Alexander, your option 2 could be done automatically. By appending postfixes to the overloaded name depending on the parameter types. Increasing the number of letters used till the ambiguity is fully resolved.</div>




<div><br></div><div>What do you think?</div><div><br></div><div><br></div><div>fillRect_RF_B ( const QRectF & rectangle, const QBrush & brush )</div><div>fillRect_I_I_I_I_BS ( int x, int y, int width, int height, Qt::BrushStyle style )</div>




<div>fillRect_Q_BS ( const QRect & rectangle, Qt::BrushStyle style )</div><div>fillRect_RF_BS ( const QRectF & rectangle, Qt::BrushStyle style )</div><div>fillRect_R_B ( const QRect & rectangle, const QBrush & brush )</div>




<div>fillRect_R_C ( const QRect & rectangle, const QColor & color )</div><div>fillRect_RF_C ( const QRectF & rectangle, const QColor & color )</div><div>fillRect_I_I_I_I_B ( int x, int y, int width, int height, const QBrush & brush )</div>




<div>fillRect_I_I_I_I_C ( int x, int y, int width, int height, const QColor & color )</div><div>fillRect_I_I_I_I_GC ( int x, int y, int width, int height, Qt::GlobalColor color )</div><div>fillRect_R_GC ( const QRect & rectangle, Qt::GlobalColor color )</div>




<div>fillRect_RF_GC ( const QRectF & rectangle, Qt::GlobalColor color )</div><div class="gmail_extra"><br><br></div></div></blockquote></div><div>I believe this alternative was considered in the original blog post Alexander wrote: this is, in essence, mangling. It makes for ugly function names, although the prefix helps in locating them I guess.<br>



<br><br></div><div>Before we talk about generation though, I would start about investigating where those overloads come from.<br></div><div><br></div><div>First, there are two different objects being manipulated here:<br>



</div><div><br>+ QRect is a rectangle with integral coordinates<br></div><div>+ QRectF is a rectangle with floating point coordinates<br><br></div><div><br></div><div>Second, a QRect may already be build from "(int<i> x</i>, int<i> y</i>, int<i> width</i>, int<i> height</i>)"; thus all overloads taking 4 hints instead of a QRect are pretty useless in a sense.<br>



<br></div><div>Third, in a similar vein, QBrush can be build from "(Qt::BrushStyle)", "(Qt::GlobalColor)" or "(QColor const&)". So once again those overloads are pretty useless.<br><br></div>



<div><br></div><div>This leaves us with:<br><br></div><div>+ fillRect(QRect const&, QBrush const&)<br>+ fillRect(QRectF const&, QBrush const&)</div><div><br></div><div>Yep, that's it. Of all those inconsistent overloads (missing 4 taking 4 floats, by the way...) only 2 are ever useful. The other 10 can be safely discarded without impacting the expressiveness.<br>



</div><br><div><br></div><div>Now, of course, the real question is how well a tool could perform this reduction step. I would note here that the position and names of the "coordinate" arguments of "fillRect" is exactly that of those to "QRect"; maybe a simple exhaustive search would thus suffice (though it does require semantic understanding of what a constructor and default arguments are).<br>



</div><br></div><div class="gmail_quote">It would be interesting checking how many overloads remain *after* this reduction step. Here we got a factor of 6 already (should have been 8 if the interface had been complete).<br>



<br>It would also be interesting checking if the distinction int/float often surfaces, there might be an opportunity here.<span><font color="#888888"><br><br><br></font></span></div><span><font color="#888888"><div class="gmail_quote">


-- Matthieu<br></div></font></span><div><div class="gmail_quote"><br></div>
<div class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">



Alexander Tsvyashchenko wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
<div style="font-family:Verdana,Geneva,sans-serif">
<p>So far I can imagine several possible answers:</p>
<ol>
<li>"We don't care, your legacy C++ libraries are bad and you should feel bad!" - I think this stance would be bad for Rust and would hinder its adoption, but if that's the ultimate answer - I'd personally prefer it said loud and clear, so that at least nobody has any illusions.<br>




<br></li>
<li>"Define & maintain the mapping between C++ and Rust function names" (I assume this is what you're alluding to with "define meaningful unique function names" above?) While this might be possible for smaller libraries, this is out of the question for large libraries like Qt5 - at least I won't create and maintain this mapping for sure, and I doubt others will: just looking at the stats from 3 Qt5 libraries (QtCore, QtGui and QtWidgets) out of ~30 Qt libraries in total, from the 50745 wrapped methods 9601 were overloads and required renaming.<br>




<br>Besides that, this has a disadvantage of throwing away majority of the experience people have with particular library and forcing them to le-learn its API.<br><br>On top of that, not for every overload it's easy to come up with short, meaningful, memorable and distinctive names - you can try that exercise for <a href="http://qt-project.org/doc/qt-4.8/qpainter.html#fillRect" target="_blank">http://qt-project.org/doc/qt-4.8/qpainter.html#fillRect</a> ;-)<br>




<br></li>
<li>"Come up with some way to allow overloading / default parameters" - possibly with reduced feature set, i.e. if type inference is difficult in the presence of overloads, as suggested in some overloads discussions (although not unsolvable, as proven by other languages that allow both type inference & overloading?), possibly exclude overloads from the type inference by annotating overloaded methods with special attributes?<br>




<br></li>
<li>Possibly some other options I'm missing?</li><span><font color="#888888">
</font></span></ol><span><font color="#888888">
<div>
<pre>-- <br>Good luck!                                     Alexander</pre>
</div>
</font></span></div>
<br></div><div>_______________________________________________<br>
Rust-dev mailing list<br>
<a href="mailto:Rust-dev@mozilla.org" target="_blank">Rust-dev@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/rust-dev" target="_blank">https://mail.mozilla.org/listinfo/rust-dev</a><br>
<br></div></blockquote></div><br></div></div>
<br>_______________________________________________<br>
Rust-dev mailing list<br>
<a href="mailto:Rust-dev@mozilla.org" target="_blank">Rust-dev@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/rust-dev" target="_blank">https://mail.mozilla.org/listinfo/rust-dev</a><br>
<br></blockquote></div><br></div></div></div>
<br>_______________________________________________<br>
Rust-dev mailing list<br>
<a href="mailto:Rust-dev@mozilla.org" target="_blank">Rust-dev@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/rust-dev" target="_blank">https://mail.mozilla.org/listinfo/rust-dev</a><br>
<br></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>