Many times one must create a variable before a function call:


  int x = 3;
  foo(x);
  writeln(x);

and this is fraught with problems such as dependencies(move or change the second line and one has to validate how the first line is affected along with all the others).

A new an improved technique, which consolidates the two lines in to one is to automatically have the compiler define the variable:

foo(x = 3);
writeln(x); // x was implicitly created in this scope by foo.

The the type of x is inferred from the type of the parameter for foo and it is initialized to 3 before calling foo(which may be optimized away, say, if the compiler can deduce that the initial state of x is not needed).

foo(x = 3);


is semantically equivalent to

  int x = 3;
  foo(x);

by requiring an initialized value using the equal size, disambiguates instantiation and prevents instantiation of mistyped variables which would not give a compile time error. With init, defaults can be used.


The problems for both cases are identical as far as one only gains a bit better localization.


The notation may seem a little funky but it is perfectly valid since this is as simple rewrite rule(direct isomorphic correspondence law).

On 16/08/2018 2:58 AM, Everlast wrote:
> The notation may seem a little funky but it is perfectly valid since this is as simple rewrite rule(direct isomorphic correspondence law).

Except there is one little problem with it.

It already exists. Its called AssignExpression but it does not not declare said variable. It's from C. Personally I'm of the opinion that it can go to the nether and have a swim.

On Wednesday, 15 August 2018 at 14:58:40 UTC, Everlast wrote:
> foo(x = 3);


C# 7 brought something similar for out params.
> int.tryParse("1234", out int myNum);

Based on this approach, I would argue, that a reasonable syntax would also contain the type, which leads to something like the following:
> foo(int x = 3);
> foo(auto x = 3);


But I don't think this feature is worth having in D.

On Wednesday, 15 August 2018 at 15:31:14 UTC, 0xEAB wrote:
> On Wednesday, 15 August 2018 at 14:58:40 UTC, Everlast wrote:
>> foo(x = 3);
>
>
> C# 7 brought something similar for out params.
>> int.tryParse("1234", out int myNum);
>
> Based on this approach, I would argue, that a reasonable syntax would also contain the type, which leads to something like the following:
>> foo(int x = 3);
>> foo(auto x = 3);
>
>
> But I don't think this feature is worth having in D.

The whole point of the syntax is just sugar... although it does reduce dependency issues ever so slightly. If one has to declare the type it reduces it's effectiveness. Of course, if it is necessary for some reason then it can be used. It obviously helps reduce ambiguities but since D can infer the type from the function then it shouldn't be necessary(but could be optional). Basically auto could be implied when not explicit. This is a little different than an isolated definition because D can infer the type here in most cases(maybe templates would cause grief though).

The point one really has to ask is what problems does it solve and what problems does it create.

The problems it solves can be reduced typing and better localization. It is minor, not a huge advancement, but the path to heaven is paved with small stones.

The problems it creates: I can't think of any that do not already steam from the base problem. If D has assignment syntax that can be used inside function arguments then it would be ambiguous and in that case the type would need to be required to solve that problem.

On Wednesday, 15 August 2018 at 16:56:39 UTC, Everlast wrote:
>>> foo(int x = 3);
>>> foo(auto x = 3);
> If one has to declare the type it reduces it's effectiveness.

auto is not a type ;-) Having e.g. auto or a type makes it clear that a new variable is being defined. I'd like this to work inside a parenthesized expression too, not just for function calls.

> since D can infer the type from the function

I think this would complicate function overload resolution. If an initial value is required the type can be inferred from that, then no changes are needed to overload resolution.

On Wednesday, 15 August 2018 at 14:58:40 UTC, Everlast wrote:
> Many times one must create a variable before a function call:
>
>
>   int x = 3;
>   foo(x);
>   writeln(x);
>
> and this is fraught with problems such as dependencies(move or change the second line and one has to validate how the first line is affected along with all the others).
>
> A new an improved technique, which consolidates the two lines in to one is to automatically have the compiler define the variable:
>
> foo(x = 3);
> writeln(x); // x was implicitly created in this scope by foo.

Couldn't you do what you need to do with UFCS and possibly a tee function if you need to add things like writeln into the chain that don't pass the data on?

On Wednesday, 15 August 2018 at 14:58:40 UTC, Everlast wrote:
> Many times one must create a variable before a function call:
>
>
>   int x = 3;
>   foo(x);
>   writeln(x);
>
> [...]

check this out:

void main() {
    import std.stdio;
    writeln = 4;
}

https://run.dlang.io/is/0wgWtw