<p>I think we can use "auto ref".</p>
<div class="gmail_quote">2011/08/08 21:45 "Michel Fortin" <<a href="mailto:michel.fortin@michelf.com">michel.fortin@michelf.com</a>>:<br type="attribution">> On 2011-08-07 20:42:30 +0000, bearophile <<a href="mailto:bearophileHUGS@lycos.com">bearophileHUGS@lycos.com</a>> said:<br>
> <br>>> This is a recently opened (not by me) enhancement request thread:<br>>> <a href="http://d.puremagic.com/issues/show_bug.cgi?id=6442">http://d.puremagic.com/issues/show_bug.cgi?id=6442</a><br>>> <br>
>> It proposes something that I remember was discussed and refused two <br>>> times in past: to require (but only optionally!) "ref" and "out" at the <br>>> calling point, as C#4 instead always requires (optionally for COM):<br>
>> <br>>>     void foo(ref int bar) { ... }<br>>>     int i = 0;<br>>>     foo(ref i);   // <------- here<br>>> <br>>>     void foo(out int bar) { ... }<br>>>     int i = 0;<br>
>>     foo(out i);   // <------- here<br>>> <br>>> <br>>> Jonathan M Davis has then argued that they clutter the code, and that <br>>> making them optional makes them kind of useless. See the thread for <br>
>> more details.<br>>> <br>>> -----------------<br>>> <br>>> After thinking some about it, I have suggested a related but <br>>> alternative proposal: to ask only for the "out" at the calling point, <br>
>> make it obligatory if you compile with -warning and optional otherwise <br>>> (for a long time "override" was like this). I think having "out" at the <br>>> calling point is more useful than "ref".<br>
>> <br>>> […]<br>> <br>> I don't find your arguments very enticing, sorry. But I do see *one* <br>> solid reason we might want to add 'ref' and 'out', optional or not, at <br>> the call site: variadic templates.<br>
> <br>> I recently had to use getopt. You use it like that:<br>> <br>>    bool option;<br>>      int counter;<br>> <br>>       getopt(args,<br>>              "option|o", &option,<br>>                "counter|c", &counter);<br>
> <br>> The problem is that taking addresses of a stack variable is disabled in <br>> SafeD, which means getopt doesn't work in SafeD, which puts SafeD in a <br>> strange position.<br>> <br>> It'd work if we used 'ref' parameters. The problem is that getopt is <br>
> defined like this:<br>> <br>>    void getopt(T...)(ref string[] args, T opts);<br>> <br>> Using a type tuple makes it impossible to have 'ref's where they need <br>> to be, hence the use of pointers.<br>
> <br>> Type tuples could be made support propagating the type including the <br>> 'ref' or 'out' storage class applied on them, which would allow you to <br>> write this:<br>> <br>>  getopt!(string, ref bool, string, ref int)(args,<br>
>            "option|o", option,<br>>             "counter|c", counter);<br>> <br>> But that doesn't work with type deduction. It could work however if you <br>> allowed specifying the 'ref' as part of the argument list:<br>
> <br>>     getopt(args,<br>>              "option|o", ref option,<br>>                 "counter|c", ref counter);<br>> <br>> I'd prefer if we had a solution that doesn't require you to write 'ref' <br>
> at the call site, but I haven't found any. Ideas?<br>> <br>> <br>> -- <br>> Michel Fortin<br>> <a href="mailto:michel.fortin@michelf.com">michel.fortin@michelf.com</a><br>> <a href="http://michelf.com/">http://michelf.com/</a><br>
> <br></div>