Back to Questions
2.6k
views10
comments
Feature request - Named arguments for let-bound functions
f#

I couldn't find it discussed and it may be I'm missing something, but it could be nice to have named arguments for let bound functions.

The easiest implementation could be just ability to supply names without reordering anything, just to make the code more readable. Another option can be allowing reordering of the prefix of the supplied argument set. The later is more difficult if the arguments are expressions with side effects.

.

Hi Yanov,

I think this a common request and a valid one.

I'd like to extend this request by asking for named arguments for discriminated unions. Not sure this is viable, but I know that unions are compiled to a class hierarchy representation, so why not allow properties on these classes so:

1
2
3
4
5
6
7
8
9
10
11
12

type Transport =
    | Car of (Make: string) * (Model: string)
    | Bicycle
    | Bus of (Route: int)
    
let bigred      = Bus(Route = 13)
let smallgreen  = Car(Make = "Triumph", Model = "TR7")


printfn "Into town on route %A" bigred.Route
printfn "Out of town in my %A"  smallgreen.Make

What do you think?

regards,

Danny

By on 5/29/2009 8:35 AM ()

It's a great idea. Makes the code more readable and it seems it is easy to implement and does not break anything. Interesting question is what F# team thinks :-)

By on 5/29/2009 2:23 PM ()

Can someone from the F# team please comment on whether or not this and the similar issues will be addressed in VS2010?

I need to know so that I can make a decision as to whether or not I can continue using F# for my project.

By on 8/13/2009 3:38 PM ()

Neither named parameters for let-bound functions nor named discriminated union data are likely for VS2010.

I am not sure what 'similar issues' you are referring to.

We'd be interested to know what you're up to that makes these "make-or-break features" (they seem like just 'nice to haves', and you can do named parameters for member functions and you can use record types as data on DUs if you really want names everywhere there).

By on 8/13/2009 4:16 PM ()

Sorry, I should have elaborated; I did mean named parameters for discriminated unions, CLR delegates and interfaces.

Bear with me while I go on a bit of a pseudo-philosophical rant to explain why this feature is more than just aesthetic to me.

As a class library author, interfaces with proper parameter names are nice-to-haves for my users, and F# is a nice-to-have for me. A very-nice-to-have. But if I had to choose between a nice-to-have for my users and a very-nice-to-have for me, I will choose the former.

This might seem strange to you coming from one of your users. You might think that I should be doing things in the way that's best for me. But the same aforementioned reasoning should apply to you as well: I highly doubt that implementing #light was very fun for you or your team, but you did it anyway, because it's nice for your users to have.

I don't want to be preachy, but it would be nice if you could keep in mind that we have developer users of our own that we want to treat well too.

By on 8/13/2009 5:32 PM ()

But just to point something out: If choice is F# or not-F#, then not-F# won't have discriminated unions at all. If your users are consuming the F# code from, say, C#, you'll probaby want to stick to the common CLR structures, like interfaces and classes, which do have names. So, you don't have to _lose_ anything to be able to use F#. You just might not be able to use all of F# to deliver a library your users want.

By on 8/13/2009 7:40 PM ()

For what it worth,

As a person doing PL/SQL programming for a living (where named argument passing is a norm) and kicking tires on functional programming at .NET, I was a bit surprised that support for named arguments is not available for let-bound functions.

It seems a bit illogical to go to great lengths of sophisticated type infrence, allow passing arguments as tuples or in curried form, yet allow named arguments only on method calls.

I guess, it's more of "nice to have" feature. Yet, it just feels like an artificial restriction. And, if something doesn't feel logical, it generates natural resistance.

By on 9/30/2009 7:39 AM ()

Yes, I wasn't aware that parameters in CLR interface methods could be named.

By on 8/13/2009 8:01 PM ()

Gothca. Yes, some people are developing apps, whereas others are developing libraries/APIs, and there are different considerations depending on which you're doing.

To be crystal clear, CLR "interfaces" do have parameters names, a la

1
2
3
4
5
6

 

type IFoo =
    abstract Foo : x:int * y:string -> int

but I think perhaps you mean 'interface' in the more generic sense, a la

1
2
3
4
5
6
7
8

 

type SomeDU =
    | Bar of int * string // would like to doc the meaning of these two
    
Bar( // and then get intellisense names here

in which case yes, we definitely want it too, but it probably will not make it for VS2010. Note that you can do

1
2
3
4
5
6
7

 

type SomeDU =
    /// Bar(age,name)
    | Bar of int * string

in which case you do get the doc comment in the hover-tooltip.

We'll also be moving the 'generate html doc' functionality into the powerpack, which will make it easier to customize API doc generation if that suits you.

Hope that is some useful info to help make an informed decision, and do ask if you have further followup questions.

By on 8/13/2009 6:39 PM ()

Thanks, that's all great news for me.

By on 8/13/2009 6:51 PM ()

    Topic tags

    IntelliFactory Offices Copyright (c) 2011-2012 IntelliFactory. All rights reserved.
    Home | Products | Consulting | Trainings | Blogs | Jobs | Contact Us | Terms of Use | Privacy Policy | Cookie Policy     		Built with WebSharper