Ticket #61 (closed enhancement: wontfix)

Opened 9 months ago

Last modified 7 months ago

Keyword args?

Reported by: JarrettBillingsley Assigned to: JarrettBillingsley
Priority: major Milestone: MiniD 2
Component: Language Keywords:
Cc:

Description

How about something like this:

function f(a, b, vararg, kwarg)
{
    writefln("a = {}, b = {}", a, b)
    for(i: 0 .. #vararg)
        writefln("vararg[{}] = {}", i, vararg[i])

    foreach(k, v; kwarg)
        writefln("kwarg[{}] = {}", k, v)
}

f(1, 2, 3, x: 4, y: 5)

Which would output something like:

a = 1, b = 2
vararg[0] = 3
kwarg[x] = 4
kwarg[y] = 5

?

I like it, and I wonder if it would be possible to somehow "accelerate" the keyword args by putting restrictions on what you can do with it. Like make it not an actual table but a pseudo-table where you can index it, index-assign it, forward it, foreach over it, # it, but it's not a real table object. This way the interpreter could use a faster implementation than creating a new table object upon every call to a kwarg function.

Change History

(in reply to: ↑ description ) 03/04/08 06:13:31 changed by Ligustah

Everything that is somehow introducing more speed is good, isnt it?

Will you make 'kwarg' a new keyword then (like 'vararg') ?

Ligustah

03/04/08 09:12:27 changed by JarrettBillingsley

:) Well I really like keyword arguments (and sure wish D had them!), but in most/all of the languages I've seen that have them (like Python), they're made inefficient by forcing allocation of a new object every time you call the function, which seems silly given that it'll probably only contain a couple values at most. So I always like to see if I can get most of the functionality of otherwise slow-to-implement features but with better performance.

Yes, I plan on making 'kwarg' (or something else, if you have other suggestions) a keyword like 'vararg'.

04/28/08 00:53:26 changed by JarrettBillingsley

  • status changed from new to closed.
  • resolution set to wontfix.

Hrm. I've been going over this.

The problem is not so much the implementation, but the amount of complexity it would add to the language is dissuading me. I'm thinking that in order to keep the language and the compiler simple, I'll pass this feature by.