Optional arguments with defaults #1122
Replies: 16 comments 53 replies
-
|
Would default arguments always have to be the last argument(s)? Aka would the following be acceptable: |
Beta Was this translation helpful? Give feedback.
-
|
That was one of my questions, aye. My initial thought is that it would not be permitted, the same as labels are not permitted before unlabelled arguments today. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah I think that's sensible, consistent too. |
Beta Was this translation helpful? Give feedback.
-
I think it's the only way it makes sense. There's precedent: that's also how TypeScript and Python's typing works. |
Beta Was this translation helpful? Give feedback.
-
|
What is the expected behaviour when piping to a function where all the arguments are optional? Also, if multiple optional params have the same type does it simply follow left-to-right ordering? |
Beta Was this translation helpful? Give feedback.
-
If I've got and I do Side note: with or without piping, what would the syntax be if I explicitly wanted to bind "bye" to param |
Beta Was this translation helpful? Give feedback.
-
Yup that's right
You'd need to supply a value for thing("hello", _) |
Beta Was this translation helpful? Give feedback.
-
|
Oh gotcha, that makes sense 😄 |
Beta Was this translation helpful? Give feedback.
-
|
What if I wanted to use the default value for The
to which I would respond: that is confusing and disallowing it would be a plus. |
Beta Was this translation helpful? Give feedback.
-
|
That problem is not related to pipes. You have the same problem when you want to use default arguments but the function doesn't use labels: fn foo(bar = 0, baz = 0, bor = 0) { }
foo(bor: 1) // doesn't work because `bor` is a positional arg
foo(0, 0, 1) // works, but requires that `bar` and `baz` are specifiedAnd with pipes: 1 |> foo(bor: _) // doesn't work because `bor` is a positional arg
1 |> foo(0, 0, _) // works, but requires that `bar` and `baz` are specifiedTherefore I'd recommend to always add labels to optional arguments: fn foo(bar bar = 0, baz baz = 0, bor bor = 0) { } |
Beta Was this translation helpful? Give feedback.
-
This seems like a really cool addition, but I worry if abused that it could lead to overly complicated function signatures. From a clarity perspective, it would be much more legible to relegate this kind of thing to just rebinding with |
Beta Was this translation helpful? Give feedback.
-
|
We would have something like |
Beta Was this translation helpful? Give feedback.
-
|
Wouldn't an Option only be necessary if a default value is not provided? Unless I'm misunderstanding something, which is very possible 😅 |
Beta Was this translation helpful? Give feedback.
-
|
Yes, but we may want to default to something other than pub type ServiceConfig {
ServiceConfig(
port: Int = 80
)
}Here a port can be supplied, but it can also use a default port of 80. If it defaulted to |
Beta Was this translation helpful? Give feedback.
-
|
Oh I see what you mean now, I wonder how/if other languages tackle this kind of thing. |
Beta Was this translation helpful? Give feedback.
-
Having the user explicitly say it defaults to None is the simplest and least confusing. It also requires no extra special syntax:
That is also how Python's typing works: from typing import Optional
def foo(bar: Optional[int] = None):
print(bar)
foo(0) |
Beta Was this translation helpful? Give feedback.
-
|
Responding to the OP
Only after all required positional arguments
I can't foresee any incoherence from simply introducing this feature, but it would be great to incorporate the "unlabeled arguments are defaulting to a label named after them, it's just omitted" idea I mentioned in #1122 (reply in thread).
IMO that's unnecessary complication. Such thing can always be done inside of the function body anyways. I'd definitely go with disallowing it until someone comes up with an actual use-case, otherwise you might end up having to support usage of a poorly-designed/overlooked aspect for backwards compatibility. |
Beta Was this translation helpful? Give feedback.
-
|
Some good thoughts and considerations there, thank you @resolritter |
Beta Was this translation helpful? Give feedback.
-
|
To contribute to the completeness of the discussion, I feel like there was an argument against optional args with default values which is that it allows you to add an argument to a function that is already called in many places without having the compiler tell you to go and inspect those places and make sure that that option makes sense for each place. I guess this is the other side of the same coin that allows you to introduce the argument without breaking peoples compiles. I don't think this is a strong argument :) I guess the simple counter is that if you introduce an optional argument to a pre-existing function then the default value for the argument should persist previous behaviour. But to the degree to which you might not do that, the feeling is of using custom types without an exhaustiveness check for case statements. You introduce something new and the compiler doesn't force you to consider the consequences of your action. As I said, not the most compelling argument and probably entirely based on a poor experience in one particular job on a C++ code base but I thought I'd include it :) |
Beta Was this translation helpful? Give feedback.
-
|
Not take the wind out of your sail but
Gleam doesn't have exhaustiveness checks yet 😅 |
Beta Was this translation helpful? Give feedback.
-
|
I realised that as I was writing it :D |
Beta Was this translation helpful? Give feedback.
-
|
I think its valuable when a language has reduced syntax for optional bool value arguments. Say an argument 'x' defaults to false if it is not expressly written but can be set to true by just writing x instead of needing to write x=true. EDIT: I made the argument for why I think this type of approach is worth the extra syntax in my next post. EDIT: For the brief version of this, you could skip to my final suggestion in *Example 5", at the end of this post. For example, this is how they could define a function called 'compute' in the Rebol language: "You can specify refinements to the way a function operates, simply by preceding optional operation arguments with a forward slash ("/"):
Calling the function:
Quote taken from: http://www.re-bol.com/rebol.html#section-6.7 A useful example with this syntax could be something like: Example 1.
I like #1. (above) more. Its prettier and there is a kind of sensibility to thinking about the boolean argument as a refinement to the function (name) rather than just as an argument. The type of 'line' is inferred as Bool and its value is determined by its presence in a function call: if present it's True, if absent its False. Example 2. Example 3. Making it more general...the 'refinement' could be one of multiple options rather than just binary. Something like:
Then calling the function:
Example 4. (Simplifying Example 3) There could be special syntax for a case statement that simultaneously declares the arg type and does the matching...to avoid declaring the type of the arg:
// Below, the type of 'line' is inferred as Bool and its value is determined by
Example 5. My favorite and final possibility.. (Further simplifying Example 3) In summary...here I'm sketching out an efficient syntax for optional arguments using custom types in which the values of custom types can appear after the name of the function, as in:
The values 'Line' and 'ToStdErr' are optional arguments to the function print. The rationale for them appearing before the brackets is that their purpose is selecting or refining the nature of the function and therefore they belong by the name of the function. With more traditional syntax this could be written as:
When no values of these custom types appear in the function call, they default to Nill (see case statement below). The type definition for the optional variants can be omitted because it can be inferred from the case statement where they are matched.
|
Beta Was this translation helpful? Give feedback.
-
|
Just saving you 4 or 5 key strokes is usually not worth the complexity of adding a new kind of syntax. Having to write |
Beta Was this translation helpful? Give feedback.
-
|
Sorry I should have made more of a case for why I think this is valuable. I agree. Saving a small number of keystrokes at the cost of new syntax isn't a good enough reason in itself. Saving unnecessary keystrokes is a good thing but I'm more interested in readability. I think code is easiest to read if its neither too concise nor too verbose. In this case I'm trying to address the latter, but I'm also suggesting that the proposed placement of the arguments is helpful as well. The suggested syntax:
gets the message across and is substantially more concise and readable than
Putting those optional arguments with the function name enhances readability because the slash-prefixed arguments are, in their essence, refinements of the function (name). Putting the options by the function name lets us know what the function is about, up front. The function name is enhanced with code. It will take a bit of time to get accustomed to the unusual syntax, and that is a tradeoff. Gleam wants to be easy to learn, but there is a good argument for taking a few minutes to learn something that will pay dividends for ever after. It may be a valid concern that many people may feel discomfort and therefore be unwilling to learn a language with unfamiliar syntax. For that reason I would expect this suggestion to be rejected. I would argue though, that the basic meaning of the proposed syntax is immediately understandable, and the full meaning is very easy to learn. If we can make functions more readable in a functional programming language, then that would be worth considering. If we save a few keystrokes per function call along the way, then that is a bonus. In Example 5, I suggest that the type declaration for this style of argument can be inferred from the case statement where the argument is matched. That would save typing 11 lines of code for the simple example that has 11 lines of code remaining. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for this suggestion, I've not come across this feature before so it is quite interesting. Makes me think I should try Rebol some time! I have two concerns for how well this would fit in with Gleam specifically. The first is that we try to only have way of doing each thing in the language, and only one syntax for each. The theory here is that making the API of the language smaller makes it easier to learn, which is a main goal of the language. The other is that the syntax seems quite unusual. Previously we had a more unusual syntax but it seemed to put people off the language. Once we moved to a more C style syntax people were more willing to give it a try. |
Beta Was this translation helpful? Give feedback.
-
|
Basically my answer is just OK. :) I like those principles. If the advantage of having function names enhanced with code is not deemed worth maxing out the strangeness budget for, then I understand that. You're certainly making the safer bet by sticking to conventional syntax and not burdening people with too much newness. (Just for the record, though, I don't think the "different" syntaxes of lisp, smalltalk, haskell or Rebol have been their biggest challenge. I think many people have given them all a chance despite their "different" syntaxes. I think they have been largely rejected on other grounds. Having said that, your point still stands.) I'm no expert, but I think the list of great languages to take a look at (like erlang, haskell, smalltalk, prolog...) should maybe include Rebol (or its successor Red). Its an extreme case of being highly moldable. From what I can tell it seems like it would be a fun to use language. |
Beta Was this translation helpful? Give feedback.
-
|
To keep things simple, maybe an initial implementation could be limited to:
Then from there we can see if there is need for more from real world usage or if this is sufficient or if we need to break up one of these limitations if possible? |
Beta Was this translation helpful? Give feedback.
-
|
That sounds like quite a sensible set of constraints to me. I think it is good to start with a more constrained feature to start and leave the door open to additions later. |
Beta Was this translation helpful? Give feedback.
-
|
What would you imagine as a syntax? Something like this? pub fn join(strings sb: StringBuilder, with joiner: String = "-") -> String {
todo
}// maybe later:
pub type Cat {
Cat(name: String, cuteness: Int = 5)
}Edit: I was just curious if the syntax has been decided already, but yes I should have re-read the OP. Sorry. |
Beta Was this translation helpful? Give feedback.
-
|
Yup, that's what was suggested above |
Beta Was this translation helpful? Give feedback.
-
|
Added a question about degrading to anonymous functions above. |
Beta Was this translation helpful? Give feedback.
-
|
One potential solution to the "Degrading to anonymous functions" is to treat optional arguments as a sort of syntax sugar for arguments of type pub fn add(a: Int, b: Int = 1) -> Int {
a + b
}
pub fn main() {
let f = add // : fn(Int, Option(Int)) -> Int
f(1) // Callable without optional argument
f(1, None) // Explicit `None`, same as previous line
f(1, 2) // Callable with optional argument
f(1, Some(2)) // Explicit `Some`, same as previous line
}Default values would also essential be syntax sugar. The above pub fn add(a: Int, b: Option(Int)) -> Int {
let b = option.lazy_unwrap(b, fn() { 1 })
a + b
}One potential concern with this approach is that it creates a disconnect between the type the function says It would allow non-defaulted optional arguments though, which would be neat pub fn log_some_stuff(message: String, context: Option(a)) {
case context {
None -> todo
Some(x) -> todo
}
}
pub fn main() {
log_some_stuff("hello!")
log_some_stuff("hello!", get_a_value(x, y, z))
}This could also apply well to constructors! pub type Person {
// The `Bool` type makes more sense here, because you don't have to see the function implementation!
// Even if optional function arguments don't get defaults, I think optional constructor arguments definitely should
Person(name: String, cool: Bool = True)
}
pub fn main() {
// `Person` constructor has type `fn(String, Option(Bool)) -> Person`
let lpil = Person("Louis") // implicitly `cool: True`
let hayleigh = Person("Hayleigh", cool: True) // explicitly `cool: True`
} |
Beta Was this translation helpful? Give feedback.
-
|
An interesting idea! pub fn main() {
let f = add // : fn(Int, Option(Int)) -> Int
f(1) // Callable without optional argument
f(1, None) // Explicit `None`, same as previous line
f(1, 2) // Callable with optional argument
f(1, Some(2)) // Explicit `Some`, same as previous line
}In this case
I don't think we want this- it should be explicit when optional arguments are used rather than implicitly happen any time that the
This would mean that that we'd require different rules to optional arguments for constructor functions to regular functions, we'll need to have the same system for both. Function wrappingOne interesting thing about this approach is that these two values pub fn some_function(x: Int = 1) {
todo
}
let f1 = some_function
let f2 = fn() { some_function() } |
Beta Was this translation helpful? Give feedback.
-
|
I guess we could always add non-defaulted later without breaking anything 🤷♀️ |
Beta Was this translation helpful? Give feedback.
-
let f1 = some_function
let f2 = fn() { some_function() }This sort of thing is why I think optional-ness should be allowed for any function with trailing |
Beta Was this translation helpful? Give feedback.
-
|
We will definitely not be introducing any implicit optional behaviour for the option type. |
Beta Was this translation helpful? Give feedback.
-
|
This could potentially introduce some ambiguity in pipelines... pub fn do_stuff(a: Int, b: Int = 1) -> fn(Int) -> Int {
todo
}
pub fn main() {
3
|> do_stuff(4)
|> io.debug() // what do we get here?
// Could be:
// - `fn(Int) -> Int`
// - `Int`
// Depends on if the pipe is equivalent to...
// - `do_stuff(3, 4)`
// - `do_stuff(4)(3)`
// Maybe this is a good reason to get rid of the pipe operator magic?
// or maybe we could require optional arguments be preceded with `~` like in OCaml?
}Unfortunately we can't require labels, because not every function has named arguments. |
Beta Was this translation helpful? Give feedback.
-
|
This isn't ambiguous, the rules for how pipes expand will handle this no problem 👍 |
Beta Was this translation helpful? Give feedback.
-
|
Could you explain how the rules will be adjusted? From the language tour:
So the question is what happens when |
Beta Was this translation helpful? Give feedback.
-
|
Pipes will not be adjusted at all. Pipes will be unaware of optional arguments the same way pipes are unaware of labels, the function call features work the same whether it is a regular call, a pipe, or a use expression. |
Beta Was this translation helpful? Give feedback.
-
What about doing the same we do with labels, at least for now: The function loses its optionals with defaults feature and the full signature is required? This would be an easy rule to understand from a programmers point of view as well and it would be consistently in line with how we handel labels. IMHO optional args with defaults are an ergonomic feature after all to reduce a lot of repeatative boiler plate. They can also be used to specify intented defaults in public interfaces, much as labels help with understanding public interfaces. I feel it is a no issue for anon functions to not support them (same as labels) fn my_top_level_fun_with_label(my_label my_var: String) {
my_var
}
fn my_top_level_fun_with_defaults(my_label my_var = "maybe future Gleam") {
my_var
}
pub fn main() {
let my_anon_fun_without_label = my_top_level_fun_with_label // type is: fn(String) -> String
my_anon_fun_without_label("This could not be set via my_label")
let my_anon_fun_without_defaults = my_top_level_fun_with_defaults // type is: fn(String) -> String
my_anon_fun_without_defaults("This has to be specified")
}To reiterate and extend the previously suggested constraints:
|
Beta Was this translation helpful? Give feedback.
-
|
I looked at this and #1122 (comment). I think this here is sensible. I do like the idea of using Options, which reminds me of OCaml, but it's just syntactic sugar for defaulting an argument to I do like how labeled arguments in OCaml work: https://v2.ocaml.org/manual/lablexamples.html They can be required, or have default values or be optional in which cause the functions body gets None. So I like your suggestion, it's simple and clear. |
Beta Was this translation helpful? Give feedback.
-
|
Some prior art to support this. Swift indeed does not support anonymous functions with labels or default arguments. func f(a: Int, b: Int = 1) -> Int {
return a + b
}
print(
// Note: by default, functions in Swift need their labels
f(a: 3, b: 4),
f(a: 3)
)
let g = f
print(
// g(a: 3, b: 4) // Error: extraneous argument labels 'a:b:' in call
// g(a: 3) // Errors: error: extraneous argument label 'a:' in call; missing argument for parameter #2 in call
// g(3) // Error: missing argument for parameter #2 in call
g(3, 4) // Ok
)Also, although Swift supports default parameters anywhere in a function signature, the language guide asks you to put them at the end of a parameter list:
Other languagesPython is more permissive, but it passes keyword arguments as dictionaries (maps) under water: def f(a, b = 1):
return a + b
print(
f(a = 3, b = 4),
f(a = 3)
)
g = f
print(
g(a = 3, b = 4),
g(a = 3)
)OCaml (here in Reason/ReScript syntax) uses currying by default. It needs a non-optional parameter to distinguish a partially applied from a fully applied function with optional parameters: let f = (~a, ~b=1, ()) => a + b
print_int(f(~a=3, ~b=4, ()))
print_int(f(~a=3, ()))
let g = f
print_int(g(~a=3, ~b=4, ()))
print_int(g(~a=3, ())) |
Beta Was this translation helpful? Give feedback.
-
|
About restriction 2 ("For default values do not allow functions, just values"): Functions are also values! Do you mean you don't want developers to write anonymous functions as a default argument? This would be a bit too much indeed: fn f(a: Int, b: fn(Int) -> Int = fn(n) {n * 2}) {...}But I think this should be allowed: fn g(a: Int, b: fn(Int) -> Int = square) {...}Possible options to reformulate restriction 2:
|
Beta Was this translation helpful? Give feedback.
-
|
Also unless I am missunderstanding, to keep the defaults when working with anons, one could wrap I think: fn x(i: Int, my_flag b = True) {
case my_flag {
True -> i * 2
False -> i + 2
}
}
pub fn main() {
let y = fn(i) { x(i) } // fn(Int) -> Int, with applied default for my_flag
let z = fn(i) { x(i, my_flag: False) } // fn(Int) -> Int setting a value for my_flag
}
// One could also create fn ´x_with_defaults()´ as a companion to ´x()´ at top level,
// so that it becomes easy to have local function with the defaults pre-applied. |
Beta Was this translation helpful? Give feedback.
-
|
I think optional keyword arguments should not be allowed to be called positionally. fn function(a: Int, b: String = "hello world") {}
fn main() {
function(5, "hello") // this would not be allowed
function(5, b: "hello") // this is ok
}I think this because keyword arguments will have label or argument names that will add a lot of context to what the value is. Forcing users to use these will improve code readability. |
Beta Was this translation helpful? Give feedback.
-
|
What should happen instead? |
Beta Was this translation helpful? Give feedback.
-
|
I also tend to think of default arguments as a feature. This way, a library author can add functionality to a function, without requiring changes downstream. What problems do you see @lpil? |
Beta Was this translation helpful? Give feedback.
-
|
A frequent source of bugs is that the API for a program changes and the consumer isn't alerted to the change, and as such their code becomes incorrect. This is why in the OCaml ecosystem it's common to lint against wildcard patterns. I think it is less important for optional arguments, but either way avoiding breaking changes is not a major design goal and as such introducing inconsistency into the language (making arguments in some contexts not possible to give positionally) doesn't seem like a good trade. There may be other reasons to want to do this, but I don't think removing breaking changes in some situations is sufficient motivation. |
Beta Was this translation helpful? Give feedback.
-
|
I think wildcards in a In the first case, the developer can be regarded as lazy, and when the api designer changes the api, it is a source of bugs. In the second case the developer is just using a function and the api designer decides to extend the functionality of this function. I think it is perfectly fine for the designer to have the possibility to do this in a backwards compatible way (by adding a default parameter) or by using a backwards incompatible way (by adding a positional parameter). I imagine in the future Gleam'll have similar capabilities of automatic version increments as Elm has when uploading a package. Changing the signature of an existing function by adding a positional parameter would be a major update, while extending a signature with a default parameter would be a minor one. |
Beta Was this translation helpful? Give feedback.
-
|
That behaviour could be desirable, but we'll need to consider the implications of having functions degrade to anonymous functions where you cannot give any optional arguments. I do not believe anyone has started doing this work for the three proposed designs here. |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
No design issues have been resolved. We have lots of suggestions for various aspects here, but folks need to join them altogether into a single design and then explore the implications of this design, likely by writing code using it, converting existing projects, and sharing the results. This will teach us more about the trade offs, and after doing this a few times we will hopefully have a design we are happy with and can then move onto implementation. Alternatively a prototype could be made and tested, but this would not mean it can be merged. The design has to be decided first. |
Beta Was this translation helpful? Give feedback.
-
|
Which libraries would be good targets to create dummy conversions (code won't compile)? |
Beta Was this translation helpful? Give feedback.
-
|
All project are good! |
Beta Was this translation helpful? Give feedback.
-
|
gleam-lang/stdlib@afb7cee...inoas:gleam-stdlib:optional-args here is one attempt |
Beta Was this translation helpful? Give feedback.
-
PythonPython has a long history of default values for parameters. Please, prepare yourself for some horror stories :) Problems:
from typing import Any
_sentinel: Any = object()
def func_with_default_arg(arg: int = _sentinel):
if arg is _sentinel:
print('arg is deprecated!')
arg = 0
...I am not sure about how this can be approached in Gleam (
def func(arg=[]):
arg.append(1)
return arg
a = func()
assert a == [1]
b = func()
assert b == [1, 1]
assert a == [1, 1]Fix: def func(arg=None):
if arg is None:
arg = []
arg.append(1)
return argIt should not be a problem for Gleam, since everything is immutable. But still: thinking about when default arguments are evaluated is a good idea. It should probably be: every time a function is called, just to be safe: considering the fact that there are different compilation backends. And they can grow in the future.
def some(x = 1, y = 2, /):
print(x, y)
some() # no way to pass `y` without passing `x`In this case all positional-or-named parameters will also require to have default values.
Let's say you have a function like: __all__ = ['parse_and_log']
def parse_and_log(obj, verbose = False):
res = _somehow_parse_the_object(obj)
if verbose:
print(res)
return resSo, you cannot simply change This is also a point to think about in Gleam.
from collections.abc import Callable
def with_default(x: int = 0) -> int:
return x
a: Callable[[], int] = with_default
a() # ok
b: Callable[[int], int] = with_default
b(1) # ok
def some(y=0):
...And then you want to add a parameter without a default value, some regular required parameter. How would you do that? def some(x, y=0):
...^ Is a breaking change, because now users that used to call def some(*, x, y=0): # or `def some(x, *, y=0):`, both are fine
...GleamI am not a big fan of default parameter values (as you can see from the first part of my post), but they might be helpful in some case. What would I expect from them?
This way annonymous functions would not be allowed to have default values automatically, because they can't have labeled parameters.
fn x(a arg: Int = 0) -> Int {
arg
}
pub fn main() {
let a: fn(Int) -> Int = x
let b: fn() -> Int = x
}My attempt to answer open questions
pub fn add(a: Int, b: Int = 1) -> Int {
a + b
}
pub fn main() {
let f = add // What is the type of `f`?
}The type would be:
My suggestion is above.
Please, don't add purity checks just for that 🙏 Here's my suggested alternative to: pub fn write(name, message, to sink = open_log_file(name)) {
todo
}Becomes pub type SinkSpec {
DefaultSink
FileSink(name: String)
// StdOutSink
// etc
}
pub fn write(name, message, to sink: SinkSpec = DefaultSink) {
case sink {
DefaultSink -> "default io"
FileSink(name) -> "fileio: " <> name
}
} |
Beta Was this translation helpful? Give feedback.
-
|
Unless I am missing the/some points: As for when defaults are computed: I would not allow computation just scalar values. |
Beta Was this translation helpful? Give feedback.
-
The compiler could force both
strictness wins <3 |
Beta Was this translation helpful? Give feedback.
-
|
I think default values are a bad feature, especially for Gleam. Gleam optimizes so much for explicitness over implicitness (which is why many of us like it), so I do not think adding a feature that gives a convenient shortcut to implicit behavior makes sense for the language. I think default arguments are in the "easy now, can be really painful and unsustainable in the future" category of features. Other items in that category might be: implicit error propagation, allowing for variables / function parameters to be multiple types, runtime type checking / casting, variable mutability (in high level languages), and there are probably more. Gleam works hard to avoid things like this (and as such is very sustainable and refactorable), so I don't think adding default function arguments fits with the Gleam ethos. I also think Gleam has good alternatives already in place (easy syntax for the builder pattern, the I have written and worked with default function arguments in a couple different languages, and every time I did it made the code base more of a pain to work with in the long run. |
Beta Was this translation helpful? Give feedback.
-
Here's some initial thoughts on default/optional arguments.
I suspect that this would improve to the ergonomics of Gleam a lot, making some slightly tedious boilerplate avoidable.
Proposal
Default arguments in Gleam would make it so some arguments can be omitted to function calls, instead using a default value specified in the function definition.
Constructors would also accept default arguments.
The default argument value can be any expression, enabling function calls to be used.
Here the
open_log_filefunction would be called each time thewritefunction is called without a second argument.In this case we would need to have the compiler track default arguments that call functions and disallow them in constant expressions.
Like labelled arguments defaults are not part of the type system, so can only be used when referring to functions directly.
Prior art
This is inspired by the default arguments of Elixir, Scala, Ruby and OCaml.
Questions
Degrading to anonymous functions
Like labels optional arguments are a compile time feature for named functions. What should happen when a function with optional arguments is assign to a variable and degrades to an anonymous function?
What expressions are permitted in anonymous functions?
Can it be anything? Or does it have to be pure? Or a constant?
When can an argument have a default?
My initial thought was that optional arguments must come after mandatory arguments. How would this interact with labelled arguments?
Defaults that refer to earlier argument values
It could be possible to use other arguments in the expression for an existing default
Here
nameis used in the default ofsink. This could be powerful/useful, but is it desirable? We could disallow this and enable it later without any breaking change.Is this syntax good?
Largely just copied Scala here. Other ideas welcome!
Beta Was this translation helpful? Give feedback.
All reactions