User-defined Functions: support namespacing, description, optional args, default values

[clintgibler]

There are a number of useful aspects of defining methods in most languages that are currently not supported (or at least appear to be not supported) for user-defined functions in Darklang:

• Namespacing: being able to group your functions into namespaces, like the stdlib allows (e.g. Twitter::send_tweetv0)
• Description: stdlib functions support a short description when you're calling them to understand what they do and how their args are used. User-defined functions should support this as well.
  • This could either be a separate field in the box at the top where you define the name and args (maybe best option) or assume that the first statement in the function, if it's in the form, let _ = "..." is the comment.
• Optional args and default values: arguments you don't have to pass in. If you don't, they take the defined default values
  • Perhaps the default could be a third column when defining an argument - name, type, default value.
• Allow versioning: stdlib functions support versioning, e.g. HttpClient::postv5 but user-defined functions and datastores do not.

[pbiggar]

Optional args and default values: arguments you don't have to pass in. If you don't, they take the defined default values

• Perhaps the default could be a third column when defining an argument - name, type, default value.

I'd like to do this. Do you have any thoughts for how to call functions with optional parameters in the editor (as in, what do you type to learn about, add, remove, etc, optional arguments)?

[clintgibler]

Hm that's a good question. I'm not sure the best way to do this, I'll have to think about it more.

Perhaps the easiest way to handle this would be to require all optional arguments to have a default value, and when you autocomplete that function in the editor, the default values are placed in at the calling location- saving the user some typing, but letting them replace the value if they want.

I'm not sure if this is maximally flexible, but it also make implementation on Dark's side a bit easier. Perhaps reasonable for a V0?

[StachuDotNet]

Closing this issue, as it's not quite applicable to dark-next:

• namespacing, descriptions, and versioning are supported in dark-next already
• I'm going to extract out the request for "optional args" to the Component: Language and Interpreter #5243 issue, though I think our support for Option, along with the ease of creating 2 fns (one with the defaults in place) limit how useful of a feature this might be