On 2/28/11 2:22 AM, Bekenn wrote:
> On 2/28/2011 12:04 AM, Jonathan M Davis wrote:
>> You could be linking to code where you don't _have_ the source and
>> don't _have_
>> the names of the variables. It's all done by the function signature in
>> C, C++,
>> Java, C#, D, etc. The names of the variables are completely irrelevant to
>> calling the function, and so any linkers that follow C conventions (as
>> with
>> happens with D) _must_ be able to deal with function calls based on their
>> signatures. That doesn't necessarily mean that it would be
>> _impossible_ to find a
>> way to have named arguments in D, but it makes it _far_ harder.
>>
>> - Jonathna M Davis
>
> Again, I don't see why that's a problem; you can't call a function if
> you don't have a function declaration somewhere (perhaps in a .di file).
> The compiler would do parameter name lookup based on the current
> module's view of the function space.
>
> If you truly don't have a declaration, then that means you're calling
> through a function pointer or a delegate. Again, no problem: either a)
> the function pointer or the delegate specifies names for the arguments,
> or b) it doesn't, in which case you simply can't use named arguments.
>
> I'm absolutely not suggesting that parameter names should be part of the
> ABI, nor am I suggesting that function declarations must present
> parameter names; if names aren't available to the module at compile
> time, then you can't use named arguments. Where's the problem?

I don't see any.

One more thing, order of evaluation should still be left-to-right, not in order of arguments. This means the feature cannot be a syntactic rewrite (not a big issue, but definitely something to keep in mind).


Andrei

On 02/28/2011 01:41 PM, Michel Fortin wrote:
> On 2011-02-28 02:03:46 -0500, Bekenn <leaveme@alone.com> said:
>
>> Potential problems: The only problems I can foresee here are variations on
>> the situation when there are two (or more) versions of a function with the
>> same number, type, and names of parameters, but in non-matching order, like
>> this:
>>
>> void func(int a, char b);
>> void func(char b, int a);
>>
>> In such a case, the compiler should diagnose an error if named arguments are
>> employed.
>>
>> Thoughts?
>
> Another problem is what happens if you override a function by using different
> parameter names. For instance:
>
> class A {
> void func(int foo);
> }
> class B : A {
> void func(int bar);
> }
>
> Currently, the above is allowed. Would it now become an error?
>
> I think it'd be much easier to support named arguments if we didn't allow
> reordering. I know I'm stripping the proposal from one of its main benefits,
> but I think the essence remains. This would make the rather common pattern of
> adding a comment for each argument compiler-verifiable without disrupting
> things too much:
>
> draw(null, // text
> null, // font
> 12, // size
> 0, // flags
> );
>
> draw(text: null,
> font: null,
> size: 12,
> flags: 0);
>
> It would be implemented as a check for equality of the argument names after
> overload resolution. No ABI change, no interaction with overloading, just an
> extra check that if an argument name is specified it must match the one in the
> declaration.

+++ Make things simple!
Since positional arguments is the main & historic parameter-passing method, just keep order.
For me, allowing unordered arguments is just a (somewhat nice) side-effect of naming. The huge gain by far is "semantic unload" talen out of programmer shoulders ; and self-documentation. Just like in your example.
The latter point (self-doc) also has a big benefit in terms of language learning: if code samples use named args, then understanding and memorising common funcs and other tools can be far easier.

> There'd still be a funny interaction with overriding (see my first example),
> but you can always leave your argument unnamed if the definition keep changing
> the name in unpredictable ways.

I would say: name mismatch --> error. Meaning "x.func(foo=1)" throws if method lookup ends up selecting "B.func" (meaning x is a B); conversely "x.func(bar=1)" throws if method lookup ends up selecting "A.func" (meaning x is an A but not a B).

Denis
-- 
_________________
vita es estrany
spir.wikidot.com

On 2/28/11 6:48 AM, Andrej Mitrovic wrote:
> I prefer using the equals sign:
> foo(action = "dofoo", times = 100)
>
> This is how Python does it.

// in a module far, far away
void fun(double x);

// In a module importing it
int x = 42;
fun(x = 43);


Andrei

On 2/28/11, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> On 2/28/11 6:48 AM, Andrej Mitrovic wrote:
>> I prefer using the equals sign:
>> foo(action = "dofoo", times = 100)
>>
>> This is how Python does it.
>
> // in a module far, far away
> void fun(double x);
>
> // In a module importing it
> int x = 42;
> fun(x = 43);
>
>
> Andrei
>

Yes, I've mentioned I was wrong in my next-to-last post. :)

On 02/28/2011 02:01 PM, Steven Schveighoffer wrote:
> On Mon, 28 Feb 2011 07:48:24 -0500, Andrej Mitrovic
> <andrej.mitrovich@gmail.com> wrote:
>
>> I prefer using the equals sign:
>> foo(action = "dofoo", times = 100)
>>
>> This is how Python does it.
>
> This syntax already means something in D:
>
> string action;
> int times;
> foo(action = "dofoo", times = 100); // set action to "dofoo" and times to 100
> and pass those to the function.

This is *very* bad imo. But since it's inherited from C we cannot change it (acoording to D design principles).
So, let's use ':'.

Denis
-- 
_________________
vita es estrany
spir.wikidot.com

On 2/28/11 8:16 AM, Andrej Mitrovic wrote:
> On 2/28/11, Andrei Alexandrescu<SeeWebsiteForEmail@erdani.org>  wrote:
>> On 2/28/11 6:48 AM, Andrej Mitrovic wrote:
>>> I prefer using the equals sign:
>>> foo(action = "dofoo", times = 100)
>>>
>>> This is how Python does it.
>>
>> // in a module far, far away
>> void fun(double x);
>>
>> // In a module importing it
>> int x = 42;
>> fun(x = 43);
>>
>>
>> Andrei
>>
>
> Yes, I've mentioned I was wrong in my next-to-last post. :)

Apologies - I replied to posts this morning as I was seeing them, a practice I need to change.

Andrei

On 2011-02-28 09:34:30 -0500, spir <denis.spir@gmail.com> said:

> So, let's use ':'.

Note however that ':' already has a meaning in templates arguments. Using ':' for named function arguments would preclude having named template arguments (or force template arguments to use yet another syntax).

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

On 2011-02-28 09:55:54 -0500, Michel Fortin <michel.fortin@michelf.com> said:

> On 2011-02-28 09:34:30 -0500, spir <denis.spir@gmail.com> said:
> 
>> So, let's use ':'.
> 
> Note however that ':' already has a meaning in templates arguments. Using ':' for named function arguments would preclude having named template arguments (or force template arguments to use yet another syntax).

Oops, sorry. I was mixing up template definition and template instanciation. Turns out there's no real problem:

	template Test(T : U) { }

	Test!(T: int);

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

On Mon, 28 Feb 2011 09:55:54 -0500, Michel Fortin <michel.fortin@michelf.com> wrote:

> On 2011-02-28 09:34:30 -0500, spir <denis.spir@gmail.com> said:
>
>> So, let's use ':'.
>
> Note however that ':' already has a meaning in templates arguments. Using ':' for named function arguments would preclude having named template arguments (or force template arguments to use yet another syntax).

I think you are confusing template declarations with template instantiations.  ':' is not used in instantiations (that I know of)

e.g. the usage would be:

template foo(T = int, U = string) {...}

foo!(U : int)...;

-Steve

On 02/28/2011 03:55 PM, Michel Fortin wrote:
> On 2011-02-28 09:34:30 -0500, spir <denis.spir@gmail.com> said:
>
>> So, let's use ':'.
>
> Note however that ':' already has a meaning in templates arguments. Using ':'
> for named function arguments would preclude having named template arguments (or
> force template arguments to use yet another syntax).

Yes, I'm aware of that. This usage in fact conflicts with the general "subtyping" semantics of ':'. But this conflict already exists with the usage of ':' in dyn array notation, which is linguistically pretty close to a named argument set; so...

Denis
-- 
_________________
vita es estrany
spir.wikidot.com