> bearophile Wrote:
> > This is a recently opened (not by me) enhancement request thread: http://d.puremagic.com/issues/show_bug.cgi?id=6442
> 
> D is the language to save keystrokes. This proposal is plain invalid.

We're not going to reject a feature proposal simply because it involves more typing (unless it's excessive). What matters are what overall advantages and disadvantages it provides. Saving keystrokes is nice, but it's generally not enough of a reason to accept or reject a feature proposal. D does generally let you do more in less code than C++, but saving keystrokes is just a nice bonus on top of everything else that it provides, not the reason for its existance.

- Jonathan M Davis

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

KennyTM~ Wrote:

> I disagree. If you want to save keystrokes, use Perl.

Perl is dynamically typed, right? D is statically typed, so it can statically check most things like out variables won't overwrite const arguments.

FWIW, Google's C++ style guide explicitly requires passing pointers to arguments (whenever possible) when they are to be modified or used as out parameters, and passed by const& when they are not. This makes it more obvious at the caller's end which parameters are going to be modified and which ones aren't.

--
Ziad


On Mon, Aug 8, 2011 at 12:23 PM, Kagamin <spam@here.lot> wrote:

> KennyTM~ Wrote:
>
> > I disagree. If you want to save keystrokes, use Perl.
>
> Perl is dynamically typed, right? D is statically typed, so it can statically check most things like out variables won't overwrite const arguments.
>

Ziad Hatahet:

> FWIW, Google's C++ style guide explicitly requires passing pointers to arguments (whenever possible) when they are to be modified or used as out parameters, and passed by const& when they are not.

It's here: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Reference_Arguments

Bye,
bearophile

On 2011-08-08 18:30:10 +0000, Kagamin <spam@here.lot> said:

> Michel Fortin Wrote:
> 
>> I recently had to use getopt. You use it like that:
>> 
>> 	bool option;
>> 	int counter;
>> 
>> 	getopt(args,
>> 		"option|o", &option,
>> 		"counter|c", &counter);
>> 
>> The problem is that taking addresses of a stack variable is disabled in
>> SafeD, which means getopt doesn't work in SafeD, which puts SafeD in a
>> strange position.
> 
> const opts = getopt(args);
> const option = opts.get!bool("option|o");
> const counter = opts.get!int("counter|c"); // also reusable

Thanks for the tip.

That said it doesn't invalidate my complain about 'ref' and 'out' being unusable in conjunction with type tuple arguments. If you're going to write a function that forwards its parameters to another function, using a type tuple to make it generic will fail in the presence of 'ref' and 'out' parameters in the wrapped function.

-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/