8

EDIT 1: I know there are alternatives such as telescoping, this was a purely educational question.

I know that this is true, but why must it be? It seems like with something like this:

public class Foo{

    private int bar;

    public void SetBar(int baz = ThatOtherClass.GetBaz(3)){
        this.bar = baz;
    }

}

The compiler could change the method to something like this:

public void SetBar(int baz){

//if baz wasn't passed:
baz = ThatOtherClass.GetBaz(3);

this.bar = baz;

}

Why wouldn't that work, or would it, and it's just a design decision?

AlphaModder
  • 3,266
  • 2
  • 28
  • 44
  • because there can be a difference between runtime values and compile-time values. what if the coder wanted a compile-time value "hardcoded" in there, but GetBaz() then returns something completely different at runtime and throws the program out of whack? – Marc B Oct 07 '14 at 18:42
  • 5
    If you want to know why the C# language team didn't implement a feature then ask them, rather than random developers that had nothing to do with the creation of the language. We can't know why they chose not to implement this feature. – Servy Oct 07 '14 at 18:42
  • 1
    you always have the option of method overloading – Logan Murphy Oct 07 '14 at 18:43
  • 1
    I don't know why, however if you want a work around to be able to do this just make a overload without the parameter instead of using a default parameter `void SetBar() { SetBar(ThatOtherClass.GetBaz(3)) }; void SetBar(int baz) { this.bar = baz; }` – Scott Chamberlain Oct 07 '14 at 18:44
  • I know that there's alternatives, I was just wondering if anyone knows why it wasn't added, if there was a logical reason that the code wouldn't work, or that the developers of C# just decided not to. And as for Marc B's comment, i suppose that's true, but if he wanted a compile-time constant why would he have used a method that isn't constant in the first place? – AlphaModder Oct 07 '14 at 18:45
  • 2
    @user1825860 The fact that you know exactly how to accomplish this shows you that it most certainly *is* possible. It's a feature that the language team choose not to spend the time and money to build. If you want to know why that is, you can try asking them (although I wouldn't hold your breath). All that we could do is guess why they didn't prioritize doing this. – Servy Oct 07 '14 at 18:47
  • possible duplicate of http://stackoverflow.com/questions/23036827/why-cant-i-give-a-default-value-my-optional-parameter-except-null – Selman Genç Oct 07 '14 at 18:47
  • What if the *dynamic* default value returns null? Thanks god, you could use a default value in that case - oh... wait... :-) – dognose Oct 07 '14 at 18:48
  • @dognose what do you mean? If this was supported and `GetBaz` returned `int?`, then you could just do `public void SetBar(int baz = ThatOtherClass.GetBaz(3) ?? 0)`, but in some cases you would actually want the dynamic default to return `null`. – David Sherret Oct 07 '14 at 18:57
  • It is restricted by what can be expressed in a .NET assembly. You can read more about it in Ecma 335, chapter II.15.4.1.4 shows what a parameter declaration can look like, chapter II.16.2 describes what's possible for FieldInit. With the most severe constraint that it can't be code, only constants. – Hans Passant Oct 07 '14 at 19:25

1 Answers1

7

Because the spec says so:

A fixed-parameter with a default-argument is known as an optional parameter, whereas a fixed-parameter without a default-argument is a required parameter. A required parameter may not appear after an optional parameter in a formal-parameter-list. A ref or out parameter cannot have a default-argument. The expression in a default-argument must be one of the following:

• a constant-expression

• an expression of the form new S() where S is a value type

• an expression of the form default(S) where S is a value type

As to why the language designers chose to do this, that we can only guess at. However, another piece of the spec hints at an answer:

When arguments are omitted from a function member with corresponding optional parameters, the default arguments of the function member declaration are implicitly passed. Because these are always constant, their evaluation will not impact the evaluation order of the remaining arguments.

BradleyDotNET
  • 60,462
  • 10
  • 96
  • 117
  • yeah thats a good point, if you use methods as your default values which order should those methods be executed if you have more than one default value and at which time – Logan Murphy Oct 07 '14 at 18:49