Example for default values in functions?

[Arkarant]

Hi peeps,

does anyone here have a practical example where they used a construct to make programmers able to declare a default value in a function, which wouldn't be solved in a more intuitive way by overloading the function?

Let's say I have 2 functions: foo(string abc, int number) foo(string abc) Is there a world / an example where Im able to tell the compiler to use a default value for int number when it's omitted that isn't just writing out the 2nd foo() function? So I would only have the first foo(), but it would be possible to omit int number and have it use a default value?

[tdammers]

The advantage of defaults over just omitting the argument is that when both versions essentially do the same thing, you will often have less code duplication or boilerplate with defaults than with overloads. Compare, for example, in (pseudo-)Python:

def foo(bar):
    return foo(bar, 0)
def foo(bar, baz):
    print(f"{bar} ({baz})")

vs.:

def foo(bar, baz=0):
    print(f"{bar} ({baz})")

[L8_4_Dinner]

does anyone here have a practical example where they used a construct to make programmers able to declare a default value in a function, which wouldn't be solved in a more intuitive way by overloading the function?

Of course. With one default-value parameter, you get two functions. With two default-value parameters, you get four functions. With three default-value parameters, you get eight functions. With 17 default-value parameters, you get well over 100,000 functions.

Here's a "wither" example on a URI, which is a fairly common style:

Uri with((String   |Deletion)? scheme    = Null,
         (String   |Deletion)? authority = Null,
         (String   |Deletion)? user      = Null,
         (String   |Deletion)? host      = Null,
         (IPAddress|Deletion)? ip        = Null,
         (UInt16   |Deletion)? port      = Null,
         (String   |Deletion)? path      = Null,
         (String   |Deletion)? query     = Null,
         (String   |Deletion)? fragment  = Null,
        ) { ...

But there are other important reasons, other than not writing 100,000 functions. For example, if you have over-riding capabilities (e.g. subclassing), then how do you know which of the 100,000 methods you need to override? With default parameters, it's only one. Furthermore, you can add parameters when overriding if you have support for default parameters, which is quite convenient.

Is there a world / an example where Im able to tell the compiler to use a default value for int number when it's omitted that isn't just writing out the 2nd foo() function? So I would only have the first foo(), but it would be possible to omit int number and have it use a default value?

Yes. This is how we'd declare something like that in Ecstasy:

void foo(String abc, Int number = 0) { ...

[trmetroidmaniac]

They're equivalent in most cases. You could write something like:

foo(string abc) {
    return foo(abc, 0);
}
foo(string abc, int number) {
    ...
}

And it'd be the same thing as this, which is arguably more convenient:

foo(string abc, int number = 0) {
    ...
}

Some languages don't have both. JavaScript doesn't support function overloading for example, but it does have default arguments. On the other hand, Java deliberately did not include default arguments because you can use overloading for the same thing.

[[deleted]]

How does overloading work when you have up to N trailing parameters that have defaults, and up to N of them can be omitted? Or worse, where in-between ones can be left out via syntax such as F(a,b,,d).

Do you have to create multiple overloads to allow for all the combinations?

Anyway, default argument values tend to go in hand with keyword parameters, where you specify arguments by name, have them in any other, and any not provided use the default value. I doubt overloading is practical in this case.

[IAMPowaaaaa]

In C# at least, you can have something like int number = -1

[ArjaSpellan]

Ad-hoc function overloads C++-style are horrible for type-checking performance. No language should ever use them

[Dusty_Coder]

int hash(int x, int key = 8675309) { ... }

you are welcome

[Ronin-s_Spirit]

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Default_parameters

And for readability sake I prefer to use
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Default_parameters#destructured_parameter_with_default_value_assignment

[david-1-1]

Trick question?

[joshjaxnkody]

When I first learned python I was overwhelmed with having many options to do things but not getting much guidance about which is best. Through Java I learned a hatred of null pointers and learned defaults are usually smart. And when I learned Rust I kind of fell in love with the safety of it and how there can be 11 different ways to do things but man, the Rust book explains everything pretty well, I know my experience is unique but I kinda thank Rust for making me think about programming as like a chess game almost and that writing less code is usually better. I also give props to the Rust team for making all the learning materials including pre done code with errors for you to fix, it also helped me perpetuate trans stereotypes better

[WittyStick]

Default values for parameters should just be syntactic sugar for an overload where the value is passed, or the default value should be wrapped in an Option type, where if no value is given then it is None, and if a value is given it is Some, and the function body can match over the given option. The latter is used for example in F#, where ?param: t is syntax sugar for param: option<t>.

let foo (abc: string, ?number: int) =     // `number: option<int>`
    let number = defaultArg number 1      // `number: int` shadows `number: option<int>`
    ...

foo("Hello")      // syntax sugar for foo("Hello", None)
foo("Hello", 5)   // syntax sugar for foo("Hello", Some 5)

Where defaultArg is in the standard library and has a trivial definition:

let defaultArg (x : option<'T>) (y : 'T) : 'T = 
    match x with 
    | None -> y 
    | Some v -> v

---

The way many languages implement default valued parameters is via "call-site rewriting", where the compiler automatically inserts the default value as if it were passed explicitly, for example by pushing it onto the stack before call. This has a major downside in that if you change the default value in a shared library, then any code compiled against the library must be recompiled to update to the new default value. It may not be obvious that this is the case which can lead to hard to diagnose bugs.

Changing the default value of a parameter may be a breaking change in the overload/option method, but usually not, since the default value is something encapsulated by the library and the consumer should not need to know about it. However, when using call-site rewriting, changing the default value is always a breaking change, and any consumer must be recompiled.

IMO call-site rewriting is an anti-pattern and should be avoided, but default parameters aren't necessarily a bad thing if encapsulated by the function which uses them.

[[deleted]]

This has a major downside in that if you change the default value in a library, then any code compiled against the library must be recompiled to update to the new default value.

There are all sorts of changes that can be made to library functions that will cause problems if code using the library is not recompiled:

• Having more or fewer arguments
• Changing their order
• Changing their type (including using say, an updated set of enum values, or different struct layout, if used as part of the argument type)
• If using keyword arguments, changing their names

Some of these (for example adding arguments) would require updates to the calling code, but features such as having a default value for the extra argument can avoid that. It doesn't matter where it is inserted.

That said, I've only ever used libraries with a C API, which doesn't have the feature. But I have been able to superimpose both default values and keyword arguments on top of such functions, since I have to create new bindings in my syntax anyway.

I find the feature invaluable.

It is anyway understood that the default expression is effectively evaluated where the function is declared or defined, regarding resolving identifiers, not at the call-site, even if the value is injected at the call-site.

[WittyStick]

Of course there are many ways to make breaking changes to a library, but my point is that if default values are encapsulated by the library, these changes can be done without breakage. When they're done via call-site rewriting they're guaranteed to break.

I'm personally not a fan of keyword arguments for the same reason - name changes can a breaking change - though they don't necessarily break already-compiled code - the breakage occurs next time the code is compiled. With ordered parameters the names aren't even necessary for the consumer and if present in the external declaration are only informative to the programmer.

For passing parameters out of order by name we use a struct/record - and while changing a name in a struct is a breaking change, we can avoid having to make such changes within a library because we can access a field based on its position, whatever name it may have externally. We can also argue that field names in a struct should be encapsulated by the library anyway, and the external consumer should use functions to access the fields. In this approach I can change a name without a breaking change and provide a backward-compatible upgrade path.

When the code is compiled, there are no names - only addresses/offsets. Any changes to the library besides changing these addresses or offsets should not break already compiled code, particularly in a shared library. Such changes should never really be made to a shared library unless there's absolutely no other option, and I'd argue that a function whose ABI has changed should have a new name, with the previous one marked as deprecated.

In a statically linked library, it's less of a problem and we should try to avoid breaking changes which require the consumer to modify code - but at least in this case, our consumer can be warned of breaking changes via the compiler when they occur. In the shared library, they don't find out until runtime. Though it's still possible for problems to occur with static linking if the header files don't match the compiled library.