On Tuesday 09 November 2010 23:55:26 spir wrote:
> Hello,
> 
> Is there a way for a func to hold 2 optional params of the same type?
> 	void f(int p, bool b1=false, bool b2=false) {
> 	    writefln("p=%s b1=%s b2=%s", p,b1,b2);
> 	 }
> Or is there a workaroud?

Try compiling it. It works just fine.

You should be able to have multiple optional parameters, and their types shouldn't matter. Where you get into trouble is if that function has overloads which conflict. Since, in effect, by declaring

void f(int p, bool b1 = false, bool b2 = false)

you've declared

void f(int p, bool b1, bool b2)
void f(int p, bool b1)
void f(int p)

So, trying to declare any of those three separately won't work because your first definition covers them all.

- Jonathan M Davis

On Wed, 10 Nov 2010 00:30:55 -0800
Jonathan M Davis <jmdavisProg@gmx.com> wrote:

> On Tuesday 09 November 2010 23:55:26 spir wrote:
> > Hello,
> > 
> > Is there a way for a func to hold 2 optional params of the same type?
> > 	void f(int p, bool b1=false, bool b2=false) {
> > 	    writefln("p=%s b1=%s b2=%s", p,b1,b2);
> > 	 }
> > Or is there a workaroud?
> 
> Try compiling it. It works just fine.
> 
> You should be able to have multiple optional parameters, and their types shouldn't matter. Where you get into trouble is if that function has overloads which conflict. Since, in effect, by declaring
> 
> void f(int p, bool b1 = false, bool b2 = false)
> 
> you've declared
> 
> void f(int p, bool b1, bool b2)
> void f(int p, bool b1)
> void f(int p)

Precisely, what a clear exposure of the issue! Sorry, my question was far to imprecise. I cannot have
	void f(int p, bool b2) {}
If I call it with a single bool param, then D logically maps it to b1. In a language with named params, one would simply write
	f(whatever, b2=true);

Is there any workaround?
I thought at replacing b2 by a variable external to the func itself. Eg instead
	void test (args, failure=false, silent=false) {}
have
	SILENT_TEST = false;
	void test (args, failure=false) {... also use SILENT_TEST ...}
But I find the solution a bit weird, it breaks lexical scoping, and forces the user to overwrite a variable in the func's original scope (module).
(Is this at all possible:
	import foo;
	foo.K = true;
I'll try...)

> So, trying to declare any of those three separately won't work because your first definition covers them all.

Right, thank you, Jonathan.

> - Jonathan M Davis

Denis
-- -- -- -- -- -- --
vit esse estrany ☣

spir.wikidot.com

On Wed, 10 Nov 2010 09:16:05 -0500, spir <denis.spir@gmail.com> wrote:

> On Wed, 10 Nov 2010 00:30:55 -0800
> Jonathan M Davis <jmdavisProg@gmx.com> wrote:
>
>> On Tuesday 09 November 2010 23:55:26 spir wrote:
>> > Hello,
>> >
>> > Is there a way for a func to hold 2 optional params of the same type?
>> > 	void f(int p, bool b1=false, bool b2=false) {
>> > 	    writefln("p=%s b1=%s b2=%s", p,b1,b2);
>> > 	 }
>> > Or is there a workaroud?

What about using a bitfield?

enum : ubyte
{
   b1 = 1;
   b2 = 2;
}

void f(int p, ubyte flags = 0)
{
   bool _b1 = flags & b1;
   bool _b2 = flags & b2;
   ...
}

f(x, b1);
f(x, b2);
f(x, b1|b2);

-Steve

On Wed, 10 Nov 2010 11:03:27 -0500
"Steven Schveighoffer" <schveiguy@yahoo.com> wrote:

> On Wed, 10 Nov 2010 09:16:05 -0500, spir <denis.spir@gmail.com> wrote:
> 
> > On Wed, 10 Nov 2010 00:30:55 -0800
> > Jonathan M Davis <jmdavisProg@gmx.com> wrote:
> >
> >> On Tuesday 09 November 2010 23:55:26 spir wrote:
> >> > Hello,
> >> >
> >> > Is there a way for a func to hold 2 optional params of the same type?
> >> > 	void f(int p, bool b1=false, bool b2=false) {
> >> > 	    writefln("p=%s b1=%s b2=%s", p,b1,b2);
> >> > 	 }
> >> > Or is there a workaroud?
> 
> What about using a bitfield?
> 
> enum : ubyte
> {
>     b1 = 1;
>     b2 = 2;
> }
> 
> void f(int p, ubyte flags = 0)
> {
>     bool _b1 = flags & b1;
>     bool _b2 = flags & b2;
>     ...
> }
> 
> f(x, b1);
> f(x, b2);
> f(x, b1|b2);
> 
> -Steve

Oh, yes, thank you! That's a very good idea.


Denis
-- -- -- -- -- -- --
vit esse estrany ☣

spir.wikidot.com

On Wednesday, November 10, 2010 06:16:05 spir wrote:
> On Wed, 10 Nov 2010 00:30:55 -0800
> 
> Jonathan M Davis <jmdavisProg@gmx.com> wrote:
> > On Tuesday 09 November 2010 23:55:26 spir wrote:
> > > Hello,
> > > 
> > > Is there a way for a func to hold 2 optional params of the same type?
> > > 
> > > 	void f(int p, bool b1=false, bool b2=false) {
> > > 
> > > 	    writefln("p=%s b1=%s b2=%s", p,b1,b2);
> > > 
> > > 	 }
> > > 
> > > Or is there a workaroud?
> > 
> > Try compiling it. It works just fine.
> > 
> > You should be able to have multiple optional parameters, and their types shouldn't matter. Where you get into trouble is if that function has overloads which conflict. Since, in effect, by declaring
> > 
> > void f(int p, bool b1 = false, bool b2 = false)
> > 
> > you've declared
> > 
> > void f(int p, bool b1, bool b2)
> > void f(int p, bool b1)
> > void f(int p)
> 
> Precisely, what a clear exposure of the issue! Sorry, my question was far
> to imprecise. I cannot have void f(int p, bool b2) {}
> If I call it with a single bool param, then D logically maps it to b1. In a
> language with named params, one would simply write f(whatever, b2=true);
> 
> Is there any workaround?

I'm sure that you could find various ways to get around specific examples (such as using Steve's proposal of a bitfield for bools), but generally, that's just not how things work. D doesn't have named parameters. The type and order of parameters are what determines which function overload to use.

The best general case solution that I can think of is to use a struct that holds the parameters that you want to pass in. Have its fields default to whatever you want as the default and only set the fields that you want to set.

In the case of bools, you could use a bitfield as Steve suggests, or you could use named enums instead with yes and no (like Phobos does in several places) and then declare multiple versions of the functions where one takes both enums and one takes only the second one that the first takes. So, if your two bools indicated that you should go south and you should go fast, you'd do something like

enum GoSouth {no, yes};
enum GoFast {no, yes};

func(int p, GoSouth gs = GoSouth.no, GoFast gf = GoFast.no) { ... }
func(int p, GoFast gf) { ... } // likely assumes GoSouth.no


That doesn't really scale very well though. Using named enums instead of bools in some cases though can make code clearer.

In any case, the struct solution is the best that I can suggest for the general case, but really, D doesn't have named parameters. Things just don't work that way. So, trying to make things work that way is going to require bending over backwards on some level.

- Jonathan M Davis

Jonathan M Davis:

> In any case, the struct solution is the best that I can suggest for the general case, but really, D doesn't have named parameters. Things just don't work that way.

Named arguments is among my top four enhancement requests :-) They help. Hopefully in D3.

Bye,
bearophile

On Wednesday 10 November 2010 12:24:01 bearophile wrote:
> Jonathan M Davis:
> > In any case, the struct solution is the best that I can suggest for the general case, but really, D doesn't have named parameters. Things just don't work that way.
> 
> Named arguments is among my top four enhancement requests :-) They help. Hopefully in D3.

I expect that that's one of those things that those who have never used them don't see the point and those who have hate not having them. Personally, I've never used a language that had them, and I don't really care about them. I'd say that if you have parameter lists long enough to care, then your parameter lists are too long and you need to find ways to reduce them (like encapsulating related parameters into struct - using a point struct instead of separate x, y, and z values would be a great example of that). Maybe my opinion would be different if I had extensively used a language with named parameters, but I haven't yet.

Now, that doesn't mean that D definitely shouldn't have them - it could be that I'd love them once I had them - but as someone who hasn't used them, they don't seem at all necessary. So, I really think that it primarily comes down to people not being used to them seeing no need and people being used to them wanting them. Whether they are actually worth having, I really can't say.

- Jonathan M Davis

On Wed, 10 Nov 2010 12:39:15 -0800
Jonathan M Davis <jmdavisProg@gmx.com> wrote:

> On Wednesday 10 November 2010 12:24:01 bearophile wrote:
> > Jonathan M Davis:
> > > In any case, the struct solution is the best that I can suggest for the general case, but really, D doesn't have named parameters. Things just don't work that way.
> > 
> > Named arguments is among my top four enhancement requests :-) They help. Hopefully in D3.

+++

> I expect that that's one of those things that those who have never used them don't see the point and those who have hate not having them. Personally, I've never used a language that had them, and I don't really care about them. I'd say that if you have parameter lists long enough to care, then your parameter lists are too long and you need to find ways to reduce them (like encapsulating related parameters into struct - using a point struct instead of separate x, y, and z values would be a great example of that).

I fully agree with your struct example for (x,y,z). But this is an example where names, precisely, are not a real gain. The real point is not to reduce the size of a param list (they make it longer!). The real point, in my opinion, is also not avoiding the need to remember param order (and for x,y,z it's not an issue).
Why I love named parameters is that they bring embedded documentation for free; provided names are sensibly chosen, indeed. They make code much easier to read, even for the author. We don't spend our valuable time & attention in "computing" information that should be available (what's that param?). Our brain can then better work on what's important, namely the app's logics. But maybe it's only me.

> Maybe my opinion would be different if I had extensively used a language with named parameters, but I haven't yet.

I first discovered named parameters with python, and loved them before having used them even once. The idea is simply good for me. Either you care for what they bring, or not. It's not a question of beeing used to using them or not.
Probably you give more importance to other aspects of code, and less to the one (say, clarity) greatly enhanced by this feature, than I do. I'm not sure this would change with, for instance, beeing forced to use a language with _only_ named parameters (my dream language *).

> [...]

Denis

From an OO perpective, this is much easier to envision, snce the target, on which a method applies, is already told apart. Then, remaining data are really parameters in the plain sense of the term; and are usually very few. Naming them is thus less a trouble, and more helpful:
	names.sort(ALPHA, true);
	names.sort(order=ALPHA, reverse=true);

-- -- -- -- -- -- --
vit esse estrany ☣

spir.wikidot.com