[RFC FS-1095] Discussion thread for RequireNamedArgument

[smoothdeveloper]

• RFC: https://github.com/fsharp/fslang-design/blob/master/drafts/FS-1095-requirenamedargumentattribute.md
• Suggestion: Add an attribute enforcing the use of named parameters at callsite fslang-suggestions#414

I'm gonna require the name of people coming with an argument.

[laenas]

I'm curious about your thought process on a few points that weren't clear from the summary post in the suggestion thread:

1. Is this meant to be a blanket over a method, or applicable individually to specific cases of ambiguity?

type Foo() =
  [<RequireNamedArgument>]
  static member Bar(bar: int) = bar

  static member Baz([<RequireNamedArgument>] baz: int, c) = baz + c

2. What is your usage differential, pros/cons of each approach, when comparing this with the existing 'solutions' for the soft enforcement of this sort of correctness(not enforcing strict safety, but at least giving developers pause)

3. Does pipelining/composing produce an intentional backdoor to this behavior? Or does the core language need additional support for naming pipelined/composed args?

type Foo() =
  [<RequireNamedArgument>]
  static member Bar (x, y) = x + y

(1,2)
|> Foo.Bar

[laenas]

1. I haven't thought of ability to put it on argument by argument basis, I'm open to discuss it but it will broaden the scope of work in the implementation, not sure how much, it opens to a lot more edge cases AFAIU.
   It also feels slippery since named arguments, when mixed with positional, are always supposed to be at the end, so I think opening that possibility is going to be confusing and seems too fine grained as a design choice for API authors who have interest in the top level feature I intended.

I think my concern would be that without being able to apply it individually - then we end up with cases where a long function with one point of ambiguity suddenly requires an enormous call:

type Foo() =
  [<RequireNamedArgument>]
  static member Bar(alpha,bravo,charlie,delta,echo,foxtrot) = alpha + bravo + charlie + delta + echo + foxtrot

//This
Foo.Bar(1,2,3,4,5,6)

//Is forced to become this
Foo.Bar(alpha = 1, bravo = 2, charlie = 3, delta = 4, echo = 5, foxtrot = 6)

2. I want this feature for cases like FSharp.Data.SqlClient type providers, I think applying the attribute on the method in those cases saves from possible mistakes that occur when the SQL code gets adjusted, arguments can change position, and if they are of same type then it is a bug in all call sites who don't use the named argument syntax.
   I basically just want some methods to always have the named arguments syntax at call sites.
   The alternative is to use records, but can't be achieved yet with type providers.
   The soft solutions are interesting, but until we get a robust analyser framework, that works out of the box in all environments, I find they don't provide the guarantees I'm seeking.

Would such a feature be clamped to type provider cases?

When I ask about soft solutions, I mean that this feature is a thin metal guardrail that nudges a developer to pay attention, but isn't going to stop someone who wants to drive over a cliff and stop using named params.

let divide x y = Foo.Bar(dividend = x, divisor = y)
//And I can now stop worrying about sending in names again

And there already are extant solutions for these sort of soft hints that aren't going to stop someone, but will provide a named-and-checked way to help with clarity and refactoring:

[<Struct>]
type Dividend = Dividend of int

[<Struct>]
type Divisor = Divisor of int

type Divider() =
  static member Divide(Dividend dividend, Divisor divisor) = dividend / divisor

Is one, for example. Whether that works nicely in type providers, I do not personally know, having not explored that side of the language. (And I recognize that these sort of single-case unions are to taste anyway, but they already exist)

Another example, a little further afield from the core language, would be dealing with this as UOM

[<Measure>]type dividend
[<Measure>]type divisor

//snip
  static member Divide(dividend: int<dividend>, divisor: int<divisor>) = int dividend / int divisor

A tad bit messier, to strip the units, but it's already extant and is erased.

[smoothdeveloper]

then we end up with cases where a long function with one point of ambiguity suddenly requires an enormous call

this would be fine if the choice in API design was made to require named argument, it carries that consequence, if the feature doesn't come with argument by argument granularity.

To consider the feature on argument by argument basis, I'd like my points on the order of positional versus named arguments to get some more scrutiny, more exchanges (probably moving that discussion in a top level post just on the matter), do you mind starting a top level post just on that?

Would such a feature be clamped to type provider cases?

I don't feel it should only apply to type provider cases, but that was a case for me to come up with the suggestions back then, I'm currently soft enforcing this at code review stage.

let divide x y = Foo.Bar(dividend = x, divisor = y)
//And I can now stop worrying about sending in names again

This is perfectly fine, people bothered by API design choices are free to work around it and it even shouldn't be too hard. Exactly like your exemple.

For alternatives you propose:

UoM:

pros:

• has 0 runtime cost

cons:

• I suspect is call site getting messy (probably more than the case you make about lots of arguments)
• the work arounds needed to use UoM on arbitrary types in current version of the language
• need to add one type per argument (in worst case)

Single case DU:

cons:

• We don't have haskell equivalent of newtype so they carry a runtime cost.
• Some people get strong opinion against them
• need to add one type per argument (in worst case)

pros:

• this is probably already idiomatic in some APIs, hence strong opinions against them

I've used that, but can't use it in type providers.

I think the crux is that, the original suggestion felt very simple and aligning with other Require attributes (I suspect that argument is what tipped @dsyme to approve it), the alternatives seems more like twisting existing features of the language but there won't be a single best idiomatic approach.

They may feel sensible when the argument types apply to many methods, but don't address the requirement for this to just be ad-hoc annotation of methods on their own, requires more declarations and probably less natural in cases I envisioned usage of the feature.

Those solutions remain valid for functions, but for methods semantics, and the fact that F# endorse some flavour of object programming, the feature as it was expressed feels more natural and straight forward for people to pick up / become idiomatic.

Really good critical look so far.

[smoothdeveloper]

@laenas I've incorporated cues to your idea for argument per argument support in my edit PR on the RFC as well as your other feedback.

As it stands right now:

• to carry the burden of me exploring impact of support, I'd need more people piling in, and making a case for it
• if someone explores the impact of the implementation, I'd be more able to gauge if I can scope it with my work on the original suggestion, contributing experimental code (see the experimental PR) and details to the RFC will help significantly
• need feedback if it would be a different attribute or the same, just that the name is a bit lengthy for argument by argument usage
• further discussion on just that topic can be a top level comment in that discussion

Thanks a lot.

[voronoipotato]

I don't think there's any need to make it attributed argument by argument, and furthermore it appears to move away from how those attributes are used conventionally. You can always have a function that has a list of require named arguments consumed by a function which does not require it. Since it can be easily wrapped I really don't see a reason to do argument by argument, but when it is necessary for example it does seem like it could be useful to force the labeling. I could see this as a more performant alternative to single case DU, when you would like to describe the domain, and you want the developer who is working on it to mindfully notice what they are passing into the function.

[smoothdeveloper]

when you would like to describe the domain, and you want the developer who is working on it to mindfully notice what they are passing into the function.

@voronoipotato I've added this to the RFC under motivation, it really is a good summary of why the feature would be used.

[smoothdeveloper]

In the RFC, there are unresolved questions about behaviour in context of type hierarchy / virtual methods.

I'm gearing toward making the attribute enforced without the need to define it again if you override a method implementation (as well as implement in case of abstract member).

Reasoning is that if the choice is made in a base type, the design choice should carry automatically on the whole type hierarchy.

I don't think it is worth having a way to revert that with a separate attribute, it is trivial to wrap the method in another method or function that won't enforce the named arguments at call sites.

If that seems counter-intuitive or to be the wrong choice, please engage and share your point of view.

[smoothdeveloper]

There is now a suggestion for bringing the attribute to BCL: dotnet/runtime#51451