compact 'auto' declaration

[michael...@gmail.com]

Hello,

Instead of writing a long list of variables with 'auto':

/* Here we create variables for bla bla */

auto X1 = new X();

auto X2 = new X("bla bla");

....

The following new syntax could be create a more compact code:

auto {

   X1 = new X();

   X2 = new X("bla bla");

  ...

   Xn = ..

}

Thanks for reading

[Germán Diago]

The problem with this is that it looks misleading, since { usually introduces a scope, but this would be an exception to that rule.

Regards 

Thanks for reading

[michael paris]

yep, an exception!

main() {

auto {

a = 2 + 3;

x = new X();

{

 int b = a + 5;

}

//here b is out of scope!

//But if i declare b using 'auto' in this way:

auto {

b = a + 5;

}

new_var = b + a; //b is visible

{

            auto example = 2;

}

//here example is out of scope!

}

}

[Douglas Boffey]

On Monday, 3 November 2014 12:19:37 UTC, michael paris wrote:

yep, an exception!

main() {

auto {

a = 2 + 3;

x = new X();

{

 int b = a + 5;

}

//here b is out of scope!

//But if i declare b using 'auto' in this way:

auto {

b = a + 5;

}

new_var = b + a; //b is visible

{

            auto example = 2;

}

//here example is out of scope!

}

}

 

Looks too much like those languages where variables don’t need declaring for my liking :(

[Germán Diago]

El lunes, 3 de noviembre de 2014 19:19:37 UTC+7, michael paris escribió:

yep, an exception!

main() {

auto {

a = 2 + 3;

x = new X();

{

 int b = a + 5;

}

//here b is out of scope!

//But if i declare b using 'auto' in this way:

auto {

b = a + 5;

}

new_var = b + a; //b is visible

{

            auto example = 2;

}

//here example is out of scope!

}

You changed exception by inconsistency:

int a, b, c; //as always

auto a = 7, b = "hello"; //Illegal currently.

auto { //What?

    a = ...;

    b = ...;

}

Regards

[Germán Diago]

I didnt elaborate: by inconsistency I mean that variable declaration currently does not introduce a scope.

With your rule, the way you show it, auto { creates a new scope.

[Daniel Krügler]

2014-11-03 11:44 GMT+01:00 <michael...@gmail.com>:
> Hello,
>
> Instead of writing a long list of variables with 'auto':

Are you consequently suggesting this syntax for other variable forms
as well? Because I don't understand why auto should be more special
than others.

> /* Here we create variables for bla bla */
> auto X1 = new X();
> auto X2 = new X("bla bla");
> ....
>
> The following new syntax could be create a more compact code:
>
> auto {
> X1 = new X();
> X2 = new X("bla bla");
> ...
> Xn = ..
> }

This doesn't look like a serious improvement to me. To the contrary:
This makes the language unnecessary complicated and I have to tell
beginners another complete new rule about how to declare variables.

- Daniel

[sghe...@gmail.com]

On Monday, November 3, 2014 11:44:13 AM UTC+1, michael...@gmail.com wrote:

Hello,

Instead of writing a long list of variables with 'auto':

 

As others would phrase it: _what problem does it solve_? (We already have some inkling about the cost)

 

[michael paris]

Here is the idea:

main() {

typename_with_long_name a = ... 

typename_with_long_name b = ...

typename_with_long_name c = ... 

//With standard use of auto:

auto a = ...

auto b = ...

auto c = ...

//Adding to 'auto' a new rule:

auto {

a = ...

b = ...

c = ...

}

}

We use auto for two main raisons:

1) Resolving situation like :

template<class T, class U>

auto add(T t, U u) -> decltype(t + u)

{

    return t + u;

}

2) Reduce the amount of code we write every day:

instead of writing something like

  std::shared_ptr<std::map<std::string, SuperLongLongName>> variable = ...

just writing in place (when possible)

  auto variable = ....  

 So, what problem does it solve ?

 just reducing the amount of "auto" we write every day and create logical places in the code that are "typed declaration free".

Look this simple code:

/* standard way */

auto sum_int = 3 + 4;

auto sum_str = "hey" + "hey";

auto sum_float = 3.14 + 1.6;

auto &data = func_ret();

/* new way */

auto {

sum_int = 3 + 4;

sum_str = "hey" + "hey";

sum_float = 3.14 + 1.6;

&data = func_ret();

}

For my personal taste, the new way is more elegant and compact.

[Daniel Krügler]

2014-11-03 16:03 GMT+01:00 michael paris <michael...@gmail.com>:
> Look this simple code:
>
> /* standard way */
> auto sum_int = 3 + 4;
> auto sum_str = "hey" + "hey";
> auto sum_float = 3.14 + 1.6;
> auto &data = func_ret();
>
> /* new way */
> auto {
> sum_int = 3 + 4;
> sum_str = "hey" + "hey";
> sum_float = 3.14 + 1.6;
> &data = func_ret();
> }
>
> For my personal taste, the new way is more elegant and compact.

I still disagree. I see no visible advantage of the suggested new
rule. It does not make the code more readable compared to the current
state. In fact, it makes it harder to understand, because instead of
an initialization, your code form looks like an assignment. Again, I
emphasize that your new rule is completely different than existing
initialization rules and this means it has to be taught to every
programmer. If there would exist a real advantage, the latter can
outweigh the disadvantages of new rules. But from your presentation I
really don't see any convincing argument that would clarify the
advantages of the new rule.

- Daniel

[gmis...@gmail.com]

I can see some appeal in reduced typing, but I don't think the feature is worth it and every time I've started to feel the need for that feature I realised auto was the problem and overall it seems to me that:

a) it encourages excess use of auto which I dislike, e.g. auto a = 1; doesn't appeal to me over int a = 1;

b) it introduces a new syntax to learn.in an area not desperate for one.

c) I don't like indentation where it isn't a scope unless there's important some value to it.

d) I can't do anything really new with it to warrant the distraction of the committee to work on it to introduce it.

[Andy Prowl]

I think saving keystrokes is rarely a good motivation for anything. Writing "auto x =" instead of just "x =" makes code easier to read, because it clearly says "I'm declaring a variable" rather than "I"m assigning a variable", and the "auto" part makes this clear. The proposed syntax requires the reader to disambiguate assignment from initialization based on the context (are we inside an "auto" block or not?).

Having "auto" blocks is also inconsistent and confusing (why introducing unnecessary exceptions to the scoping rules? why only for "auto" and not for "int"?), and makes it harder to teach the rules.

The thing I would rather wish is a better syntax for variable initialization. The AAA style cannot be used consistently (see non-movable types), and I would love to see a uniform way of initializing variables.

Thinking aloud:

    x := val;

Or even:

    x := type{val};

Or why not:

    x : type = val;

But this is not the point of this thread.

Kind regards,

Andy

[Farid Mehrabi]

I `m not going to discuss whether it`s a good or bad idea but IMHO maybe the following syntax looks more comprehensible:

auto a1=X1(), a2=X2();

it reminds me of the old combined declaration syntax:

int i1=1, i2=2;

regards,

FM.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--

how am I supposed to end the twisted road of  your hair in the dark night??
unless the candle of your face does turn a lamp up on my way!!!

[Bengt Gustafsson]

That's how I always wanted auto to work, assuming you mean that X1 and X2 are two classes and not two functions returning int.

This is especially good for for-init statements, working with two iterators or so.