www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Automatic variable declaration

reply Everlast <Everlast For.Ever> writes:
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).
Aug 15 2018
next sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
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.
Aug 15 2018
prev sibling next sibling parent reply 0xEAB <desisma heidel.beer> writes:
On Wednesday, 15 August 2018 at 14:58:40 UTC, Everlast wrote:

 foo(x = 3);





 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.
Aug 15 2018
parent reply Everlast <Everlast For.Ever> writes:
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);





 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.
Aug 15 2018
parent Nick Treleaven <nick geany.org> writes:
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.
Aug 15 2018
prev sibling next sibling parent ixid <nuaccount gmail.com> writes:
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?
Aug 16 2018
prev sibling parent Zoadian <no no.no> writes:
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
Aug 16 2018