Improved variable declaration syntax

[hun.nem...@gmail.com]

Hi,

I took part in so many syntax debates over the years on preferred variable declaration syntax.

One of the neuralgic point of variable declaration syntax is the pointer and reference alignment style.

The root problem is the following:

int* a, b;

This declares a pointer and an int which is confusing. So a common coding style to avoid this error is aligning pointer to variables:

int *a, b;

Which is also confusing sometimes as some type parts are separated from the "main" type.

What I suggest is a new variable declaration syntax:

// <type>:= <identifier1>, <identifier2>, ...;
// so I can write

int*:= a, b;

// or

int*:= a = nullptr, b = &a;

// the following won't compile:
int*:= *a, b;

To avoid the type syntax confusion I also propose to deprecate old style variable declaration syntax as we can write tools to mechanically transform the code bases to this new syntax.

I get this syntax from a previous thread: 

A more consistent variable declaration syntax by Andy Prowl

https://groups.google.com/a/isocpp.org/forum/#!searchin/std-proposals/variable$20declaration/std-proposals/ITDME5hYiPw/l4HFz3jjik4J

Peter

[Ville Voutilainen]

On 3 April 2017 at 17:45, <hun.nem...@gmail.com> wrote:
> Hi,
>
>
> I took part in so many syntax debates over the years on preferred variable
> declaration syntax.
>
> One of the neuralgic point of variable declaration syntax is the pointer and
> reference alignment style.
>
> The root problem is the following:
>
> int* a, b;
>
> This declares a pointer and an int which is confusing. So a common coding
> style to avoid this error is aligning pointer to variables:
>
> int *a, b;
>
> Which is also confusing sometimes as some type parts are separated from the
> "main" type.

If either of those is confusing, then separate the declarations with a
semicolon and if you prefer, with a linefeed.

> What I suggest is a new variable declaration syntax:

That's a completely over-the-top solution to a non-issue that you have
other solutions for.

[Maxim Yanchenko]

Hi Peter,

The problem can be solved with simple

  #include <functional>
  std::add_pointer_t<int> a,b;

Now both a and b are pointers.

Cheers,

Maxim

--
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-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/62e66de4-7c7a-4e1c-8343-b173b49cb594%40isocpp.org.

[hun.nem...@gmail.com]

On Monday, April 3, 2017 at 4:50:24 PM UTC+2, Ville Voutilainen wrote:

On 3 April 2017 at 17:45,  <hun.nem...@gmail.com> wrote:
> Hi,
>
>
> I took part in so many syntax debates over the years on preferred variable
> declaration syntax.
>
> One of the neuralgic point of variable declaration syntax is the pointer and
> reference alignment style.
>
> The root problem is the following:
>
> int* a, b;
>
> This declares a pointer and an int which is confusing. So a common coding
> style to avoid this error is aligning pointer to variables:
>
> int *a, b;
>
> Which is also confusing sometimes as some type parts are separated from the
> "main" type.

If either of those is confusing, then separate the declarations with a
semicolon and if you prefer, with a linefeed.

The real problem is the "int *a" vs. "int* a" style mixing in the code bases. With this proposal we can get rid of the "int *a" style coding as it will pointless.

Hard to pick one style now as "writing every declaration to a new line" rule sometimes results in very unreadable code.

Peter

 

[Ville Voutilainen]

On 3 April 2017 at 18:01, <hun.nem...@gmail.com> wrote:
> The real problem is the "int *a" vs. "int* a" style mixing in the code
> bases. With this proposal we can get rid of the "int *a" style coding as it
> will pointless.

No we can't, since none of the large codebases using "int *a" would be
able to move for many years,
would probably not move even after many years, and we would spend
pointless energy implementing
this change in every C++ parser when we have much better things to do.

[hun.nem...@gmail.com]

This is technically correct but in practice require a lot of typing as you have to force the std::add_lvalue_reference and others also.

Peter

To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.

[hun.nem...@gmail.com]

Deprecating a syntax doesn't mean they can't use their code base at all. Nowadays we have tool like clang refactoring tool. With the help of a tool you can mechanically transform your code base.

Implementing this new syntax in compilers isn't really a huge task.

Peter

[Michał Dominiak]

Have you ever fought an endless battle for a tiny little change at any big corporation that writes C++? It doesn't seem you have.

--

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.

To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c61fc6d5-ceca-454c-9fe1-97091fca4b26%40isocpp.org.

[Ville Voutilainen]

On 3 April 2017 at 18:27, <hun.nem...@gmail.com> wrote:
> Nowadays we have tool like clang refactoring tool. With the help of a tool
> you can mechanically transform your code base.

No I can't, since my code must work on older compilers, and I have no
time to spend on pointless
changes that add nothing to the code.

> Implementing this new syntax in compilers isn't really a huge task.

I'm sure you've done it for gcc, clang and msvc already, not to
mention every non-compiler tool
that parses C++. Where are your patches? Never mind, don't tell me, I
don't want them.

[hun.nem...@gmail.com]

I am working in a big company as a C++ expert. Starting a new project or merging two project to one also quite stressful. But the real problem is there is no good solution to this simple task now. Variable declaration is quite weak now. You can select the "int* a" style but you can't declare more then one variable in one line. Or you can use "int *a;" style which is just simple confusing as you separated the type. 

Peter

[hun.nem...@gmail.com]

On Monday, April 3, 2017 at 5:37:04 PM UTC+2, Ville Voutilainen wrote:

On 3 April 2017 at 18:27,  <hun.nem...@gmail.com> wrote:
> Nowadays we have tool like clang refactoring tool. With the help of a tool
> you can mechanically transform your code base.

No I can't, since my code must work on older compilers, and I have no
time to spend on pointless
changes that add nothing to the code.

Adding new features will break compatibility. If you declare your code needs the -std=c++20 flag then this kind of issue will happen.

 

> Implementing this new syntax in compilers isn't really a huge task.


I'm sure you've done it for gcc, clang and msvc already, not to
mention every non-compiler tool
that parses C++. Where are your patches? Never mind, don't tell me, I
don't want them.

I wrote some compiler extension in clang. So I think it won't really be a huge change in the parse. And I don't think that my task is to patch every compiler.

Peter

[Ville Voutilainen]

On 3 April 2017 at 18:47, <hun.nem...@gmail.com> wrote:
> I wrote some compiler extension in clang. So I think it won't really be a
> huge change in the parse. And I don't think that my task is to patch every
> compiler.

It's also not my task to entertain every proposal that people come up with.

[Thiago Macieira]

On segunda-feira, 3 de abril de 2017 08:47:02 PDT hun.nem...@gmail.com
wrote:

> Adding new features will break compatibility.

No, it doesn't.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center

[Tony V E]

1. Use

int * a;

The * is important - make it clearly visible. ‎As a bonus, both other 'religions' seem to accept/tolerate it. 

2. Give up on coding styles (within reason). I know this is heretical, but I've instead just learned to be comfortable in various styles.

3. If you want this change, change it in C first. We don't need to be 100% compatible, but we don't want needless incompatibility either.

4. Don't bother. It is not worth committee time. I'd rather have concepts, modules, coroutines, ranges, networking, ...

Sent from my BlackBerry portable Babbage Device

From: hun.nem...@gmail.com Sent: Monday, April 3, 2017 11:41 AM To: ISO C++ Standard - Future Proposals Reply To: std-pr...@isocpp.org Subject: Re: [std-proposals] Improved variable declaration syntax

--
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.

To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/71d11c91-44c1-4662-a995-10735dbb735d%40isocpp.org.

[hun.nem...@gmail.com]

On Monday, April 3, 2017 at 6:08:05 PM UTC+2, Tony V E wrote:

1. Use

int * a;

The * is important - make it clearly visible. ‎As a bonus, both other 'religions' seem to accept/tolerate it. 

But this is not a solution, as I can't write:

int * a, b;

First, this looks like a multiply, second this will not do what I want here.

Writing

int* := a, b;

is what I can't write now.

 

2. Give up on coding styles (within reason). I know this is heretical, but I've instead just learned to be comfortable in various styles.

I know but I was in a situation where team A and team B wrote code in different coding style. Later the two team was merged and you know... Ok. we can pick one style but now there is no good choice here.

Peter

[Bo Persson]

On 2017-04-03 16:45, hun.nem...@gmail.com wrote:
> Hi,
>
>
> I took part in so many syntax debates over the years on preferred
> variable declaration syntax.
>
> One of the neuralgic point of variable declaration syntax is the pointer
> and reference alignment style.
>
> The root problem is the following:
>
> |
> int*a,b;
> |
>
> This declares a pointer and an int which is confusing. So a common
> coding style to avoid this error is aligning pointer to variables:
>
> |
> int*a,b;
> |
>
> Which is also confusing sometimes as some type parts are separated from
> the "main" type.
>
> What I suggest is a new variable declaration syntax:
>
> |
> // <type>:= <identifier1>, <identifier2>, ...;
> // so I can write
>
> int*:=a,b;
>
> // or
>
> int*:=a =nullptr,b =&a;
>
> // the following won't compile:
> int*:=*a,b;
> |
>
> To avoid the type syntax confusion I also propose to deprecate old style
> variable declaration syntax as we can write tools to mechanically
> transform the code bases to this new syntax.
>

And without changing the language you can do:

int* a; int* b;

And not have any problems.




Bo Persson

[hun.nem...@gmail.com]

And without changing the language you can do:

int* a; int* b;

And not have any problems.

In this case you have to copy paste the type part which is error prone.

Consider the following

long_namespace::big_special_matrix<SoBigNumber>* := x, y, z, a, b, c;

will be

long_namespace::big_special_matrix<SoBigNumber>* x; long_namespace::big_special_matrix<SoBigNumber>* y; long_namespace::big_special_matrix<SoBigNumber>* z; ...

Do you think that this is a good solution?

Peter

[Bo Persson]

On 2017-04-03 19:50, hun.nem...@gmail.com wrote:
>
>
> And without changing the language you can do:
>
> int* a; int* b;
>
> And not have any problems.
>
>
> In this case you have to copy paste the type part which is error prone.
>
> Consider the following
>
> |
> long_namespace::big_special_matrix<SoBigNumber>*:=x,y,z,a,b,c;
> |
>
>
> will be
>
> |

> long_namespace::big_special_matrix<SoBigNumber>*x;long_namespace::big_special_matrix<SoBigNumber>*y;long_namespace::big_special_matrix<SoBigNumber>*z;...

> |
>
> Do you think that this is a good solution?
>
>

Yes, you could do

using matrix = long_namespace::big_special_matrix<SoBigNumber>;

to make the declarations shorter.

matrix* x;
matrix* y;
matrix* z;

will confuse no one.

Bo Persson

[hun.nem...@gmail.com]

Yes, you could do

using matrix = long_namespace::big_special_matrix<SoBigNumber>;

to make the declarations shorter.

matrix*   x;
matrix*   y;
matrix*   z;

will confuse no one. 

In this case you have to force developers to to create an abbreviation for every long typename during variable declaration.

And you have to declare what is long. And again you have to copy paste that type again and again.

struct A {

    using matrix = long_namespace::big_special_matrix<SoBigNumber>;

    matrix*   x;
    matrix*   y;
    matrix*   z;
};

vs.

struct A {
    long_namespace::big_special_matrix<SoBigNumber>* := x, y, z;
 };

Peter

[Nicol Bolas]

I don't believe that this comes up often enough for it to matter. I for one have never had to declare variables like that.

You're asking for a change to the language. Language changes should offer significant benefit. And thus far, the benefit just doesn't seem to come up often enough to be worthy of such a change.

[hun.nem...@gmail.com]

I don't believe that this comes up often enough for it to matter. I for one have never had to declare variables like that.

You're asking for a change to the language. Language changes should offer significant benefit. And thus far, the benefit just doesn't seem to come up often enough to be worthy of such a change.

In a technical point this is not a problem at all but in practice it cause headache. This is a proposal for syntax change that can be done automatically.

The main benefit is that you can remove a very diverging coding style from the language that simplify maintenance and teaching.

In real code bases the "int *a" and "int* a" style just competing every single time. And you can't select a real winner now.

Peter

[Ville Voutilainen]

On 3 April 2017 at 21:16, <hun.nem...@gmail.com> wrote:
> The main benefit is that you can remove a very diverging coding style from
> the language that simplify maintenance and teaching.

This proposal will not remove anything from the language, it's adding
yet another form of declaration,
so I fail to see how that simplifies teaching.

[hun.nem...@gmail.com]

I proposed to deprecate the "old" syntax. Now you can't pick up a winning coding style.

int* a;

style can't declare more then one pointer or reference variable in a line.

int *a, *b;

style split the type in two half; following this pattern many declaration looks like a multiply because they use this in function declaration also:

unknown_type * function();

because there is no winning style the two style always competing which result in diverged coding styles and diverged code bases.

Deprecating that syntax will result in a unified syntax.

How it helps in teaching? Now we tell colleges: follow the coding style whatever is in a file.

I want to tell them: variable declaration is the new style. Period.

Peter

[Ville Voutilainen]

On 3 April 2017 at 21:48, <hun.nem...@gmail.com> wrote:
> I proposed to deprecate the "old" syntax. Now you can't pick up a winning
> coding style.

That's not removing it from the language.

> Deprecating that syntax will result in a unified syntax.

No it won't. The attempt at deprecation will fail, for good reasons.

> I want to tell them: variable declaration is the new style. Period.

There's no way to get where you want to go in C++.

[Nicol Bolas]

On Monday, April 3, 2017 at 2:48:12 PM UTC-4, hun.nem...@gmail.com wrote:

I proposed to deprecate the "old" syntax. Now you can't pick up a winning coding style.

Except that you can, because "deprecate" doesn't mean the same thing as "remove". `std::auto_ptr` is still in C++11 and 14. It will only be unavailable when C++17 hits which removes it.

So long as it is available, people will continue to use it. It will not magically go away, nor will your conversion tool be widely used to make it go away. So even if you deprecated standard variable declaration syntax, you would never be able to remove it.

And of course, you have to get the C committee to accept it too; otherwise you will have created an incompatibility between the two languages, for little benefit.

How it helps in teaching? Now we tell colleges: follow the coding style whatever is in a file.

I want to tell them: variable declaration is the new style. Period.

This is not a significant enough benefit to be worth the hassle of adding another language feature, not to mention the many years of both being available.

[hun.nem...@gmail.com]

On Monday, April 3, 2017 at 8:52:22 PM UTC+2, Ville Voutilainen wrote:

On 3 April 2017 at 21:48,  <hun.nem...@gmail.com> wrote:
> I proposed to deprecate the "old" syntax. Now you can't pick up a winning
> coding style.

That's not removing it from the language.

> Deprecating that syntax will result in a unified syntax.

No it won't. The attempt at deprecation will fail, for good reasons.

I doubt. The only reason for the split type style is to able to declare more then one variable in a line. Enabling a new syntax for this the "split type style" (int *a) will be meaningless.

Deprecating old syntax will encourage the using of the new syntax and you can create auto converter for you code base.

 

> I want to tell them: variable declaration is the new style. Period.

There's no way to get where you want to go in C++.

I see the problem.

If I have a large code base of "int *a" I don't want to change.

If I have a large code base of "int* a" I don't want to change.

What I see now is a constant merge conflict generator as I have many library in both style.

The current status quo is not ideal either. I saw so many commits which convert one style to another. And later the merge conflict resolving patches for it. Then the backporting patch.

Peter 

[Nicol Bolas]

On Monday, April 3, 2017 at 3:09:28 PM UTC-4, hun.nem...@gmail.com wrote:

On Monday, April 3, 2017 at 8:52:22 PM UTC+2, Ville Voutilainen wrote:

On 3 April 2017 at 21:48,  <hun.nem...@gmail.com> wrote:
> I proposed to deprecate the "old" syntax. Now you can't pick up a winning
> coding style.

That's not removing it from the language.

> Deprecating that syntax will result in a unified syntax.

No it won't. The attempt at deprecation will fail, for good reasons.

I doubt. The only reason for the split type style is to able to declare more then one variable in a line. Enabling a new syntax for this the "split type style" (int *a) will be meaningless.

Deprecating old syntax will encourage the using of the new syntax

No, it will not.

Not everybody will use the new syntax. And so long as you cannot guarantee that everyone will convert to the new syntax, you cannot remove the old one. And if everybody knows that you will never remove the old syntax, then they're going to keep using it. They may use the new syntax in specific cases of multiple variable declarations, but they'll use the old syntax for every-day, common variable declarations.

After all, multiple variable declarations where this matters are the exception, not the norm.

The practical reality is that you can never remove the old syntax.

and you can create auto converter for you code base.

Which nobody will use. Seriously, why would you bother? It's not that important to most people.

> I want to tell them: variable declaration is the new style. Period.

There's no way to get where you want to go in C++.

I see the problem.

If I have a large code base of "int *a" I don't want to change.

If I have a large code base of "int* a" I don't want to change.

It's more "if I have a large code base of 'code that works', I don't want to change it for zero gain".

What I see now is a constant merge conflict generator as I have many library in both style.

The current status quo is not ideal either.

Nobody claimed that it was. But the cure you propose is worse than the disease, because it doesn't actually cure the disease.

[hun.nem...@gmail.com]

On Monday, April 3, 2017 at 8:57:19 PM UTC+2, Nicol Bolas wrote:

On Monday, April 3, 2017 at 2:48:12 PM UTC-4, hun.nem...@gmail.com wrote:

I proposed to deprecate the "old" syntax. Now you can't pick up a winning coding style.

Except that you can, because "deprecate" doesn't mean the same thing as "remove". `std::auto_ptr` is still in C++11 and 14. It will only be unavailable when C++17 hits which removes it.

I accept that this is a huge change as it affect almost every single line. So it needs at least a decade or two to considering removing that syntax.

 

So long as it is available, people will continue to use it. It will not magically go away, nor will your conversion tool be widely used to make it go away. So even if you deprecated standard variable declaration syntax, you would never be able to remove it.

If you get deprecate warning it will encourage you to change. 

 

And of course, you have to get the C committee to accept it too; otherwise you will have created an incompatibility between the two languages, for little benefit.

Code in 

extern "C" {}

block can use old syntax but variable declarations in header files are rare, mostly extern ones.

 

How it helps in teaching? Now we tell colleges: follow the coding style whatever is in a file.

I want to tell them: variable declaration is the new style. Period.

This is not a significant enough benefit to be worth the hassle of adding another language feature, not to mention the many years of both being available.

I think we should consider it at least. Not the biggest problem but definitely a real world problem. I think variable declaration needs an improvement.

Peter 

[Ville Voutilainen]

On 3 April 2017 at 22:19, <hun.nem...@gmail.com> wrote:
>> So long as it is available, people will continue to use it. It will not
>> magically go away, nor will your conversion tool be widely used to make it
>> go away. So even if you deprecated standard variable declaration syntax, you
>> would never be able to remove it.
> If you get deprecate warning it will encourage you to change.

If a valid variable or a function parameter declaration produces a
deprecation warning,
that will encourage users to tell their implementation vendors to
remove that deprecation
warning from their implementations and never bring it back.

> Code in
>
> extern "C" {}
>
> block can use old syntax but variable declarations in header files are rare,

extern "C" or lack of it is not a mechanism for changing language semantics.

>> This is not a significant enough benefit to be worth the hassle of adding
>> another language feature, not to mention the many years of both being
>> available.
> I think we should consider it at least. Not the biggest problem but

I think we have wasted far more time on this non-starter than we should have.

[loic.act...@numericable.fr]

With your style, is it :

int* := a;

int*:=a;

int* :=a;

int*:= a;

I see an endless merge conflit generator, but even more powerful than before, because there are more places to put a space :)

If your developers have not learned to :
- Either use a tool as a pre-commit step to uniformize format
- Or just leave format as it is, it is not worth the cost of a commit

Then you are going to have issues whatever solution you propose. And once you have one of those solutions, you don't need your language change :)

---
Loïc



---- Message d'origine ----
De : hun.nem...@gmail.com
À : "ISO C++ Standard - Future Proposals" <std-pr...@isocpp.org>
Objet : Re: [std-proposals] Re: Improved variable declaration syntax
Date : 03/04/2017 21:09:28 CEST

--

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.

To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4bf57ab0-7548-445b-9cb8-34b28ba32af9%40isocpp.org.

[hun.nem...@gmail.com]

On Monday, April 3, 2017 at 9:28:38 PM UTC+2, Loïc Joly wrote:

With your style, is it :

int* := a;

int*:=a;

int* :=a;

int*:= a;

I see an endless merge conflit generator, but even more powerful than before, because there are more places to put a space :)

No, almost every tool handle white spaces. But they can't handle the rewriting of

int* a;
int* b;

to 

int *a, *b;

Peter

[hun.nem...@gmail.com]

>> This is not a significant enough benefit to be worth the hassle of adding
>> another language feature, not to mention the many years of both being
>> available.
> I think we should consider it at least. Not the biggest problem but

I think we have wasted far more time on this non-starter than we should have.

This is a real world problem not a theoretical one. I wasted so many time debating on how should I declare a variable, what should we enforce.

The split coding style and code bases is a fact. This proposal can solve this problem.

Peter 

[Michał Dominiak]

[citation needed]

 

Peter

--
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.

To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/21619d57-cc94-49e5-b5eb-7f65d3d2ede0%40isocpp.org.

[hun.nem...@gmail.com]

On Monday, April 3, 2017 at 9:22:50 PM UTC+2, Ville Voutilainen wrote:

On 3 April 2017 at 22:19,  <hun.nem...@gmail.com> wrote:
>> So long as it is available, people will continue to use it. It will not
>> magically go away, nor will your conversion tool be widely used to make it
>> go away. So even if you deprecated standard variable declaration syntax, you
>> would never be able to remove it.
> If you get deprecate warning it will encourage you to change.

If a valid variable or a function parameter declaration produces a
deprecation warning,
that will encourage users to tell their implementation vendors to
remove that deprecation
warning from their implementations and never bring it back.

You can turn off almost every compiler warning. But you have to explicitly specify the language standard. So you have to issue a -std=c++20 or something like that.

The compiler should inform the user that there is a new syntax for this thing, It can tell what is the new syntax and how can the user convert it automatically.

And it should inform the once per translation unit to avoid warning flood. I think it can be done.

Peter

[Michał Dominiak]

The solution to "too many ways to declare a variable" is supposed to be "add more ways to declare a variable"?

 

Peter 

--
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.

To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/94ec7963-cf01-4bda-bb64-5d3ccd3d4109%40isocpp.org.

[Chris Hallock]

A current solution to "taming" awkward types that involve *, &, [], or () is to do something like

template <typename T>
using Type = T;

// Example usage
Type<int*> a, b, c, d;

[Michał Dominiak]

And just as a general note: there are industries where changing the code, even (or maybe especially?) automatically is no-go, because, say, the code needs to be certified and any change to it (including this one!) requires recertification.

To put it simply: your plan to deprecate-and-remove the current widely used syntax won't fly. It won't even be let to push back from the gate, much less allowed on a taxiway or a runway.

 

Peter

--
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.

To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2d5b3a6a-050e-4bde-bbef-a60cc8111b3f%40isocpp.org.

[hun.nem...@gmail.com]

The solution to "too many ways to declare a variable" is supposed to be "add more ways to declare a variable"?

No. I want to replace two defected way of declaring variable with a new one.

 

Peter

[hun.nem...@gmail.com]

Wow.. Looks interesting.

Peter

[Brian Bi]

You want to change the language because you and your co-workers are obsessed with having a single coding style and you can't agree on which one?

Sorry, but I think your problem simply doesn't matter.

 

Peter 

--
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-proposals+unsubscribe@isocpp.org.

To post to this group, send email to std-pr...@isocpp.org.

To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/94ec7963-cf01-4bda-bb64-5d3ccd3d4109%40isocpp.org.

--

Brian Bi

[hun.nem...@gmail.com]

And just as a general note: there are industries where changing the code, even (or maybe especially?) automatically is no-go, because, say, the code needs to be certified and any change to it (including this one!) requires recertification.

To put it simply: your plan to deprecate-and-remove the current widely used syntax won't fly. It won't even be let to push back from the gate, much less allowed on a taxiway or a runway.

 

Ok, but changing c++ standard in compilers is allowed? They can stick to -std=c++17 and that is all.

Peter 

[Michał Dominiak]

They will not want to be stuck without features from C++20 and above.

As Brian put it, your problem doesn't matter in the grand scheme of things, where it's impossible to implement your proposed solution.

 

Peter 

--
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.

To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/22aca542-e245-4f90-88e8-6ba0b80e6a88%40isocpp.org.

[hun.nem...@gmail.com]

You want to change the language because you and your co-workers are obsessed with having a single coding style and you can't agree on which one?

Sorry, but I think your problem simply doesn't matter.

 

The problem is that I have more then 100 000+ co-workers as this is a big company. Ok, not everybody is developer but you know...

And we have to use hundreds of third party libraries. 

Peter

[Michał Dominiak]

Wow, two separate strawmans in such a short mail!

The first "argument" isn't an argument, for multiple reasons:

1) It's a hyperbole. You tried to impress us with a number, hoped we will be impressed by it, and hoped that we won't notice that you immediately admitted it's nonsense. This is irritating.

2) Even if (1) wasn't true, you still aren't working with 100k other people on the same piece of code. You're divided into groups into subgroups into subgroups. And there'll always be someone in one of those subgroups that are responsible for a project or a dozen of those who will be able to make a decision everybody will have to honor. (By the way this is how you work in an environment with multiple people - you can't satistfy everyone, and democratically trying to do so is bound to waste gigantic amounts of time - just like this thread).

And the second "argument" genuinely makes me angry, because multiple people tried to stop a unification I was trying to conduct because "you can't unify this in 3rd party libraries, why would you try it in our code?". This non-argument is much, much worse than the first one, because it hinders any attempts at making progress in your own code - "because 3rd party libraries!".

Peter

--
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.

To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/88702ee5-f391-499e-a639-00608f4997d9%40isocpp.org.

[hun.nem...@gmail.com]

Wow, two separate strawmans in such a short mail!

The first "argument" isn't an argument, for multiple reasons:

1) It's a hyperbole. You tried to impress us with a number, hoped we will be impressed by it, and hoped that we won't notice that you immediately admitted it's nonsense. This is irritating.

2) Even if (1) wasn't true, you still aren't working with 100k other people on the same piece of code. You're divided into groups into subgroups into subgroups. And there'll always be someone in one of those subgroups that are responsible for a project or a dozen of those who will be able to make a decision everybody will have to honor. (By the way this is how you work in an environment with multiple people - you can't satistfy everyone, and democratically trying to do so is bound to waste gigantic amounts of time - just like this thread).

And the second "argument" genuinely makes me angry, because multiple people tried to stop a unification I was trying to conduct because "you can't unify this in 3rd party libraries, why would you try it in our code?". This non-argument is much, much worse than the first one, because it hinders any attempts at making progress in your own code - "because 3rd party libraries!".

What I want to describe is the environment where I work. This is not a monolithic code base and there is more then one dedicated developer group... and sometimes not even a single company.

And what I saw one of the biggest coding style fragmentation is the "int* a", "int *a". When I ask developers why they choose one or other the answer is that what I described in this thread.

They want to declare multiple variable in one line or they want a clear look on what the type is. My conclusion is that the current type declaration syntax is confusing enough to improve it.

The current status quo is this two-head monster. One head is the "int *a" other is the "int* a". And I think both are weak and confusing.

Peter 

[Brian Bi]

On Mon, Apr 3, 2017 at 1:32 PM, <hun.nem...@gmail.com> wrote:

Wow, two separate strawmans in such a short mail!

The first "argument" isn't an argument, for multiple reasons:

1) It's a hyperbole. You tried to impress us with a number, hoped we will be impressed by it, and hoped that we won't notice that you immediately admitted it's nonsense. This is irritating.

2) Even if (1) wasn't true, you still aren't working with 100k other people on the same piece of code. You're divided into groups into subgroups into subgroups. And there'll always be someone in one of those subgroups that are responsible for a project or a dozen of those who will be able to make a decision everybody will have to honor. (By the way this is how you work in an environment with multiple people - you can't satistfy everyone, and democratically trying to do so is bound to waste gigantic amounts of time - just like this thread).

And the second "argument" genuinely makes me angry, because multiple people tried to stop a unification I was trying to conduct because "you can't unify this in 3rd party libraries, why would you try it in our code?". This non-argument is much, much worse than the first one, because it hinders any attempts at making progress in your own code - "because 3rd party libraries!".

What I want to describe is the environment where I work. This is not a monolithic code base and there is more then one dedicated developer group... and sometimes not even a single company.

And what I saw one of the biggest coding style fragmentation is the "int* a", "int *a". When I ask developers why they choose one or other the answer is that what I described in this thread.

Why is "coding style fragmentation" such a big issue?

Since your company doesn't have a unified coding style, just follow the existing style of whatever file you're editing. And pick your own preferred style when adding a new source file. This is what everyone else does.

 

They want to declare multiple variable in one line or they want a clear look on what the type is. My conclusion is that the current type declaration syntax is confusing enough to improve it.

The current status quo is this two-head monster. One head is the "int *a" other is the "int* a". And I think both are weak and confusing.

Peter 

--

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-proposals+unsubscribe@isocpp.org.

To post to this group, send email to std-pr...@isocpp.org.

To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e504a876-5791-4eec-a1b0-fb32475d20fc%40isocpp.org.

--

Brian Bi

[hun.nem...@gmail.com]

Why is "coding style fragmentation" such a big issue?

I describe this thing as a merge conflict generator. And I saw so many wasted hours where a developer rewrite a code part from one style to another. And I took part in so many debate around coding styles.

What I found is that the main reason for the variable declaration coding style fragmentation is the inherent weakness of the current syntax.

Developers wants clear view from a type and want to declare more then one in a line. Separating type parts are confusing and writing every declaration to a new line is an ugly solution.

Currently there is no good solution. Ok, I saw in this thread a template trick that is interesting.

The result is two concurrent coding style and I think it worth eliminating it by a new syntax.

 

Since your company doesn't have a unified coding style, just follow the existing style of whatever file you're editing. And pick your own preferred style when adding a new source file. This is what everyone else does.

 

This is the current status quo.

Peter 

[Maxim Yanchenko]

> And I saw so many wasted hours where a developer rewrite a code part from one style to another. And I took part in so many debate around coding styles.

So the problem really is that in your company you don't have a style guide that is mandatory to everyone?
With all respect, let's not try to fix the lack of leadership and the weakness of management in your company with a major language change.

--

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-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.

To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/eb985b84-9bc9-4656-9dac-a6ac14303fc1%40isocpp.org.

[Péter Radics]

Your idea won't really fix (all) your issues:

void foo(int *p, const int& r); // where do you stick the * and the & ?

[ol...@join.cc]

Op maandag 3 april 2017 16:45:12 UTC+2 schreef hun.nem...@gmail.com:

I took part in so many syntax debates over the years on preferred variable declaration syntax.

One of the neuralgic point of variable declaration syntax is the pointer and reference alignment style.

The root problem is the following:

int* a, b;

This declares a pointer and an int which is confusing. So a common coding style to avoid this error is aligning pointer to variables:

int *a, b;

Which is also confusing sometimes as some type parts are separated from the "main" type.

Hi,

Does this occur (in your codebase) often?

Most of the time I initialize variables right away and then I don't do multiple variables in one statement.

 

[Peter Koch Larsen]

I have to agree with Olaf in that you in good C++ normally only
declare one variable per line - and initialize it right away.
And of course I have to agree with Ville that this proposal should be
dead from the beginning, as it is trying to solve a non-existing
problem.

/Peter

> --
> 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.
> To view this discussion on the web visit

> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/246b9dad-71d9-4878-b251-05bb1ff81294%40isocpp.org.

[hun.nem...@gmail.com]

If you have power you have everything. But I don't have enough power to force one style  EVERYWHERE. And there is no winner here. I can select one solution and force it everywhere but in that case I force an inherently bad style.

Both dominant variable declaration style has weak in some case. Booth style are unnatural.

Peter

[hun.nem...@gmail.com]

So you have an "int*" type with name "p" and a "const int&" type with name "r". Why do you want to put a space in a type? Why do you want to separate a type? The * and & signs are part of the type and they are not part of the name.

Peter

[hun.nem...@gmail.com]

I saw many cases where putting every pointer declaration to a new line was impractical. And I saw cases where a given code parts come from C. Forcing developers to put every declaration to a new line was error prone and slow.

And variable declaration is happen in classses also. Ok they are members in that case but syntax is the same.

Consider

struct SomeGraph  {
    Node* top;
    Node* posX;
    Node* posY;
    Node* posZ;
    ...
};

Peter

[Greg Marr]

On Monday, April 3, 2017 at 2:08:25 PM UTC-4, hun.nem...@gmail.com wrote:

Yes, you could do

using matrix = long_namespace::big_special_matrix<SoBigNumber>;

to make the declarations shorter.

matrix*   x;
matrix*   y;
matrix*   z;

will confuse no one. 

In this case you have to force developers to to create an abbreviation for every long typename during variable declaration.

And you have to declare what is long. And again you have to copy paste that type again and again.

struct A {
    using matrix = long_namespace::big_special_matrix<SoBigNumber>;
    matrix*   x;
    matrix*   y;
    matrix*   z;
};

vs.

struct A {
    long_namespace::big_special_matrix<SoBigNumber>* := x, y, z;
 };

You don't have to copy again and again.

 

struct A {
    using matrixPtr = long_namespace::big_special_matrix<SoBigNumber>*;
    matrixPtr x, y, z;
}

 

[hun.nem...@gmail.com]

The "int* a" coding style mostly comes with a "declare one variable per line" rule to avoid the following cases: "int* a, b"

This solution breaks that rule and also introduce an other identifier just to declare some variables.

There isn't a clean way to declare multiple pointer or reference in one line. There are two competing method and both are bad in some way.

And this dual style itself cause bugs, debates and errors. That is the reason behind this proposal.

Peter

[Greg Marr]

On Tuesday, April 4, 2017 at 12:11:10 PM UTC-4, hun.nem...@gmail.com wrote:

The "int* a" coding style mostly comes with a "declare one variable per line" rule to avoid the following cases: "int* a, b"

This solution breaks that rule

You said you wanted to declare them all on one line to avoid repeating the type.  This does that.  You can't say on one hand "I want to declare all the variables on one line to avoid repeating the type" and then on the other hand "you can't do that because it breaks the rule of declaring only one variable per line".  If you were going to only declare one variable per line, then there would be no need for your proposal.

and also introduce an other identifier just to declare some variables.

There isn't a clean way to declare multiple pointer or reference in one line. There are two competing method and both are bad in some way. 

And this dual style itself cause bugs, debates and errors. That is the reason behind this proposal.

Yes, and "this proposal" of introducing another syntax for declaring variables is also "bad in some way" as has been pointed out several times.  The other suggested proposals in this thread can be done today.  Probably the best one is the one that just adds `Type<>` around the `int *`.

[hun.nem...@gmail.com]

On Tuesday, April 4, 2017 at 7:21:41 PM UTC+2, Greg Marr wrote:

On Tuesday, April 4, 2017 at 12:11:10 PM UTC-4, hun.nem...@gmail.com wrote:

The "int* a" coding style mostly comes with a "declare one variable per line" rule to avoid the following cases: "int* a, b"

This solution breaks that rule

You said you wanted to declare them all on one line to avoid repeating the type.  This does that.  You can't say on one hand "I want to declare all the variables on one line to avoid repeating the type" and then on the other hand "you can't do that because it breaks the rule of declaring only one variable per line".  If you were going to only declare one variable per line, then there would be no need for your proposal.

It is not just me. This is not my problem. I know the two solution. And I understand why developers choose one or other method. Developers want declare variables in a common form easily. They want declare multiple variable or members in one line. They don't want to think on helper identifiers just to declare variables and members. This is the reason for the "int *a, *b;" style. On the other hand this style is confusing as the type is separated. There is a main part and a pointer or reference part. So there is an other style which keeps the type together. This is the "int* a; int* b;" style. They have to declare every variable in new line in other words they have to repeat the type part always.

So there is no good solution. Your idea is to declare a common short name for every reference or pointer type is just uncomfortable.

 

and also introduce an other identifier just to declare some variables.

There isn't a clean way to declare multiple pointer or reference in one line. There are two competing method and both are bad in some way. 

And this dual style itself cause bugs, debates and errors. That is the reason behind this proposal.

Yes, and "this proposal" of introducing another syntax for declaring variables is also "bad in some way" as has been pointed out several times.  The other suggested proposals in this thread can be done today.  Probably the best one is the one that just adds `Type<>` around the `int *`.

The current situation is that there is no good choice so we have two half solution. My proposal is to create a good one and deprecate the two half solution. 

I can imagine that force using the Type<> template usage for every variable declaration will slow down the compilation and I am not sure it will break the binary compatibility or not. I think we need a dedicated language feature for straightforward variable declaration. But I will play with this idea.

Peter 

[Nicol Bolas]

On Tuesday, April 4, 2017 at 2:04:39 PM UTC-4, hun.nem...@gmail.com wrote:

On Tuesday, April 4, 2017 at 7:21:41 PM UTC+2, Greg Marr wrote:

On Tuesday, April 4, 2017 at 12:11:10 PM UTC-4, hun.nem...@gmail.com wrote:

The "int* a" coding style mostly comes with a "declare one variable per line" rule to avoid the following cases: "int* a, b"

This solution breaks that rule

You said you wanted to declare them all on one line to avoid repeating the type.  This does that.  You can't say on one hand "I want to declare all the variables on one line to avoid repeating the type" and then on the other hand "you can't do that because it breaks the rule of declaring only one variable per line".  If you were going to only declare one variable per line, then there would be no need for your proposal.

It is not just me. This is not my problem. I know the two solution. And I understand why developers choose one or other method. Developers want declare variables in a common form easily. They want declare multiple variable or members in one line. They don't want to think on helper identifiers just to declare variables and members. This is the reason for the "int *a, *b;" style. On the other hand this style is confusing as the type is separated. There is a main part and a pointer or reference part. So there is an other style which keeps the type together. This is the "int* a; int* b;" style. They have to declare every variable in new line in other words they have to repeat the type part always.

So there is no good solution. Your idea is to declare a common short name for every reference or pointer type is just uncomfortable.

So let me make sure I have this right. You want to change the C++ language, deprecating literally every existing C++ program, all so that things are a little more "comfortable" for you. Not because the language is broken. Not because the language is lacking in some genuinely useful feature. But simply because the solution to your problem that currently exists is not entirely ideal.

We are not going to deprecate basic syntax of a 30+ year old language simply because it's slightly inconvenient. You have a PEBKAC problem, so solve it BKAC.

The problem you cite is not a problem of significance. C++'s variable declaration syntax barely rises to the level of an annoyance. An annoyance that has a slightly verbose but perfectly adequate solution.

All you have to do is tell people that, if they're going to declare multiple pointer/reference variables on a single line, they must use the `Type<>` template. There: problem between keyboard and chair solved.

We should add language features so that people are better able to solve problems. Not because they can't be bothered to follow a convention or because you have some merge conflicts due to spaces.

and also introduce an other identifier just to declare some variables.

There isn't a clean way to declare multiple pointer or reference in one line. There are two competing method and both are bad in some way. 

And this dual style itself cause bugs, debates and errors. That is the reason behind this proposal.

Yes, and "this proposal" of introducing another syntax for declaring variables is also "bad in some way" as has been pointed out several times.  The other suggested proposals in this thread can be done today.  Probably the best one is the one that just adds `Type<>` around the `int *`.

The current situation is that there is no good choice so we have two half solution. My proposal is to create a good one and deprecate the two half solution.

I can imagine that force using the Type<> template usage for every variable declaration will slow down the compilation

Why would you force every variable declaration to use a tool that is only necessary for multiple variable declarations of pointer/reference types?

and I am not sure it will break the binary compatibility or not.

`Type<T>` is an alias. It is exactly identical to `T`. It cannot break compatibility with anything, any more than `using Alias = int; Alias i;` breaks compatibility with `int i;`.
 

I think we need a dedicated language feature for straightforward variable declaration.

No, we don't. C and C++ have managed to survive for decades without them.

[Michał Dominiak]

On Tue, Apr 4, 2017 at 8:04 PM <hun.nem...@gmail.com> wrote:

and also introduce an other identifier just to declare some variables.

There isn't a clean way to declare multiple pointer or reference in one line. There are two competing method and both are bad in some way. 

And this dual style itself cause bugs, debates and errors. That is the reason behind this proposal.

Yes, and "this proposal" of introducing another syntax for declaring variables is also "bad in some way" as has been pointed out several times.  The other suggested proposals in this thread can be done today.  Probably the best one is the one that just adds `Type<>` around the `int *`.

The current situation is that there is no good choice so we have two half solution. My proposal is to create a good one and deprecate the two half solution. 

You keep thinking this is possible. It'll be better for everyone's (including yours!) time management and sanity if you just trust us on how deprecation (1) is impossible and (2) even if it wasn't impossible, would never proceed to actual removal of the feature from the language.

As others have pointed out before: just because it's deprecated will not make people convert their codebases into this new syntax.

(And that assumes it ever gets past a plenary vote in WG21. Or to a plenary vote in WG21.)

 

I can imagine that force using the Type<> template usage for every variable declaration will slow down the compilation and I am not sure it will break the binary compatibility or not. I think we need a dedicated language feature for straightforward variable declaration. But I will play with this idea.

Peter 

--

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.

To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c3647444-d0e4-4aa6-b53b-e00e91bee70f%40isocpp.org.

[Nicol Bolas]

On Tuesday, April 4, 2017 at 2:04:39 PM UTC-4, hun.nem...@gmail.com wrote:

It is not just me. This is not my problem.

But... it is your problem.

On this thread, I count 15 separate responders to your suggestion. More than half of them question the motivation for the feature and/or the cost/benefit of it. And not one of them has been supportive of it.

Granted, 16 people is not a great sample size, but I don't think it's too far of a stretch to say that it is just you.

[hun.nem...@gmail.com]

So let me make sure I have this right. You want to change the C++ language, deprecating literally every existing C++ program, all so that things are a little more "comfortable" for you. Not because the language is broken. Not because the language is lacking in some genuinely useful feature. But simply because the solution to your problem that currently exists is not entirely ideal.

We are not going to deprecate basic syntax of a 30+ year old language simply because it's slightly inconvenient. You have a PEBKAC problem, so solve it BKAC.

The problem you cite is not a problem of significance. C++'s variable declaration syntax barely rises to the level of an annoyance. An annoyance that has a slightly verbose but perfectly adequate solution.

All you have to do is tell people that, if they're going to declare multiple pointer/reference variables on a single line, they must use the `Type<>` template. There: problem between keyboard and chair solved.

We should add language features so that people are better able to solve problems. Not because they can't be bothered to follow a convention or because you have some merge conflicts due to spaces.

The current syntax is cause duality in coding style and both dominant coding style is weak in some way. This is a 30+ years weakness which should be fixed. It is not a valuable feature of the language. It is an annoying and confusing part of the language.It was inherited from the C. I think every newer language just solved this problem.

The "int *a, *b;" syntax just stupid. The type was split in for no good reason. The only benefit of this syntax is to allow multiple pointer declaration.

The current dual style situation is just bad and cause constant confusing. But I agree if somebody just using one syntax all the time this problem doesn't exist for him.

I think we should test the mass using of a Type<> template before we accept it as a real solution.

If the Type<> template is really a usable solution then we should deprecate the old "int *a, *b" style as it is just confusing and cause code fragmentation.

 

and also introduce an other identifier just to declare some variables.

There isn't a clean way to declare multiple pointer or reference in one line. There are two competing method and both are bad in some way. 

And this dual style itself cause bugs, debates and errors. That is the reason behind this proposal.

Yes, and "this proposal" of introducing another syntax for declaring variables is also "bad in some way" as has been pointed out several times.  The other suggested proposals in this thread can be done today.  Probably the best one is the one that just adds `Type<>` around the `int *`.

The current situation is that there is no good choice so we have two half solution. My proposal is to create a good one and deprecate the two half solution.

I can imagine that force using the Type<> template usage for every variable declaration will slow down the compilation

Why would you force every variable declaration to use a tool that is only necessary for multiple variable declarations of pointer/reference types?

For simplicity and to avoid errors. The code lines are changing in time so adding a new variable shouldn't cause time wasting.

Consider 

int *a;

A developer adds a new variable

int* a, b;

Boom, he wasted a compiling cycle.

 

and I am not sure it will break the binary compatibility or not.

`Type<T>` is an alias. It is exactly identical to `T`. It cannot break compatibility with anything, any more than `using Alias = int; Alias i;` breaks compatibility with `int i;`.

If this really true, then my only proposal is to deprecate the "int *a, *b;" style variable declaration as it cause errors. But it is hard to deprecate just that part. Developers accidentally can write it and they won't get compiler warning for it.

 

 

I think we need a dedicated language feature for straightforward variable declaration.

No, we don't. C and C++ have managed to survive for decades without them.

Surviving doesn't mean not changing. Surviving means adopting. Little syntax refreshing will keep it just alive.

Even the C language deprecated the old style function declartion syntax:

And what? Nothing happened. I remember the patches in gcc that just removed it from the code base and that is all.

// this was a valid syntax

void
error(message,a1,a2,a3,a4,a5,a6,a7)
        char *message;
        char *a1,*a2,*a3,*a4,*a5,*a6,*a7;
{
  fprintf(stderr,message,a1,a2,a3,a4,a5,a6,a7);
}

Peter 

[Brian Bi]

It sounds like it's not the status quo at your company. If it were, then you wouldn't have merge conflicts, because two people who are editing the same file should both follow the existing coding style in that file.

In fact, you admitted:

I saw so many wasted hours where a developer rewrite a code part from one style to another

That's the real problem right there: that your company has developers who care more about rewriting source files to suit their own preference than about actually doing productive work.

If I have a strong irrational dislike for multiple return statements in a function, should we deprecate that too? How is that any different from what you're proposing?

 

Peter 

--
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-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.

To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/eb985b84-9bc9-4656-9dac-a6ac14303fc1%40isocpp.org.

--

Brian Bi

[hun.nem...@gmail.com]

The current situation is that there is no good choice so we have two half solution. My proposal is to create a good one and deprecate the two half solution. 

You keep thinking this is possible. It'll be better for everyone's (including yours!) time management and sanity if you just trust us on how deprecation (1) is impossible and (2) even if it wasn't impossible, would never proceed to actual removal of the feature from the language.

As others have pointed out before: just because it's deprecated will not make people convert their codebases into this new syntax.

(And that assumes it ever gets past a plenary vote in WG21. Or to a plenary vote in WG21.)

I described a proposal for a language weakness.This language weakness cause coding fragmentation and continuous debates. I hope we can came up we with a good solution.

Yes, this is not the biggest problem, we shouldn't hurry we have enough time to talk about it. I accept that this will be a slow process. But we shouldn't bother the slowness if the direction is good.

I hope we can eliminate the "int* a" vs. "int *a" duality from the language in one way or another.

Peter 

[hun.nem...@gmail.com]

There was a topic recently on a forum and we agreed there that this syntax just weak. I came here with a solution to this problem.I think counting the initial responders opinions is not cover the full picture.

I think I am able to brings supporters for this topic but I don't want to. The problem is real. I can accept a better solution also.

Peter 

[gmis...@gmail.com]

Honestly, this proposal has no chance. I'm just trying to save you wasting you time.

Good luck with the next idea though. Don't give up completely.

[Michał Dominiak]

This is not about "slowness" - I don't care how long this takes not to be accepted (and I guarantee you this never even reaches plenary.)

You assert on this being a good direction. It's not. If you disagree, please write a paper and come to EWG, though if you do I hope Ville cuts the discussion down to presentation and a "do we even eant to ever talk about this" up-down vote.

I hope we can eliminate the "int* a" vs. "int *a" duality from the language in one way or another.

This "argument" is just noise, since it's trivial to unify this across a codebase with say clang-format. 

Peter 

--
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.

To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/78dd8d28-3433-41e2-b57c-d561e03c4d03%40isocpp.org.

[Edward Catmur]

On Tuesday, 4 April 2017 20:21:38 UTC+1, hun.nem...@gmail.com wrote:
>
> If this really true, then my only proposal is to deprecate the "int *a, *b;" style variable declaration as it cause errors. But it is hard to deprecate just that part. Developers accidentally can write it and they won't get compiler warning for it.
>

Actually, why not? If clang and gcc can warn about misleadingly indented if/else statements (Wmisleading-indentation) then they should be able to warn about misleading pointer/reference qualifiers in multiple variable declarations. It could be a nice feature request for someone to implement.

[hun.nem...@gmail.com]

This is not about "slowness" - I don't care how long this takes not to be accepted (and I guarantee you this never even reaches plenary.)

You assert on this being a good direction. It's not. If you disagree, please write a paper and come to EWG, though if you do I hope Ville cuts the discussion down to presentation and a "do we even eant to ever talk about this" up-down vote.

I think I wrote down the problem and I proposed a solution to it. I can't do more.

 

I hope we can eliminate the "int* a" vs. "int *a" duality from the language in one way or another.

This "argument" is just noise, since it's trivial to unify this across a codebase with say clang-format. 

I think this aspect of the language is just annoying. Not a big bug not a show stopper it is just annoying. Sometimes cause headache for the code maintainers and developers. I think we can do it better.

Peter

[Michał Dominiak]

On Tue, Apr 4, 2017, 10:15 PM <hun.nem...@gmail.com> wrote:

This is not about "slowness" - I don't care how long this takes not to be accepted (and I guarantee you this never even reaches plenary.)

You assert on this being a good direction. It's not. If you disagree, please write a paper and come to EWG, though if you do I hope Ville cuts the discussion down to presentation and a "do we even eant to ever talk about this" up-down vote.

I think I wrote down the problem and I proposed a solution to it. I can't do more.

I'm yet to see your paper formally proposed to the committee.

 

I hope we can eliminate the "int* a" vs. "int *a" duality from the language in one way or another.

This "argument" is just noise, since it's trivial to unify this across a codebase with say clang-format. 

I think this aspect of the language is just annoying. Not a big bug not a show stopper it is just annoying. Sometimes cause headache for the code maintainers and developers. I think we can do it better.

Peter

--

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.

To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/cdf7e64c-8728-4495-aa0f-9818bec965fd%40isocpp.org.

[hun.nem...@gmail.com]

I think we should just allow only the "type identifier, identifier,...;" form. This will start reducing the code fragmentation.

We should deprecate/reject/warning for "int *a, *b;" style. If the Type<> thing is working then we are in a half finished state.

Peter

[Michał Dominiak]

Let's be blunt: which part of "there's no chance in hell this ever passes EWG, not to even talk about getting voted on by the entire committee" do you not understand?

Perhaps you'll understand it better if you write an actual proposal and get rejected by EWG explicitly.

--

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.

To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4fcbfa7b-f33f-452b-97cf-53847d179826%40isocpp.org.

[hun.nem...@gmail.com]

I'm yet to see your paper formally proposed to the committee.

Do you think I should create a proposal on this topic?

I think the original C style variable declaration is flawed.

int* a, b;

should declare

int* a;
int* b;

but it creates

int* a;
int b;

This semantic is confusing enough so there is a large supporters of the declare only one variable per line group.

So the current proposal is to deprecate this old style type split declaration.

We should introduce a helper alias template in global namespace.

template<class T>
using var = T;

so the new style is

int* test()
{
   double x, y, z;
   var<int*> a, b;
   ...
}

struct A
{
   var<Node*> first, last;
   size_t size;
};

I will thinking on this approach...

Peter 

[hun.nem...@gmail.com]

On Tuesday, April 4, 2017 at 10:33:43 PM UTC+2, Michał Dominiak wrote:

Let's be blunt: which part of "there's no chance in hell this ever passes EWG, not to even talk about getting voted on by the entire committee" do you not understand?

Perhaps you'll understand it better if you write an actual proposal and get rejected by EWG explicitly.

I have no idea who is who and what the roles are here. I have to use thing language and I have to teach it and I have to work with it. This is my job. I saw weakness in the language that is why I want to improve it.

The problem is given and I think this is the right forum to move things forward.

Peter 

[Michał Dominiak]

There's literally an entire section of the isocpp.org website dedicated to the process. https://isocpp.org/std.

One would think you'd check that out before posting on isocpp's forums related to that particular process.

--

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.

To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2ab9507a-8982-44f0-8daa-1b5504b5a4f0%40isocpp.org.

[hun.nem...@gmail.com]

On Tuesday, April 4, 2017 at 10:48:58 PM UTC+2, Michał Dominiak wrote:

There's literally an entire section of the isocpp.org website dedicated to the process. https://isocpp.org/std.

One would think you'd check that out before posting on isocpp's forums related to that particular process.

I read it some years ago so this list was in my bookmark. Maybe I should post this idea to ISO C++ Standard - Discussion first or something like that.

But I don't want to spend more time with this if this kind of change is impossible.

Peter 

[Greg Marr]

On Tuesday, April 4, 2017 at 4:57:44 PM UTC-4, hun.nem...@gmail.com wrote:

On Tuesday, April 4, 2017 at 10:48:58 PM UTC+2, Michał Dominiak wrote:

There's literally an entire section of the isocpp.org website dedicated to the process. https://isocpp.org/std.

One would think you'd check that out before posting on isocpp's forums related to that particular process.

I read it some years ago so this list was in my bookmark. Maybe I should post this idea to ISO C++ Standard - Discussion first or something like that.

No, that forum is for discussion of the existing standard.  This forum is for discussion of proposals for changes, so you found the right forum for your discussion. The next step in a change is writing up a formal proposal as described on the linked website.  However, as various people have described, this type of change would be unlikely to even be considered.

[hun.nem...@gmail.com]

No, that forum is for discussion of the existing standard.  This forum is for discussion of proposals for changes, so you found the right forum for your discussion. The next step in a change is writing up a formal proposal as described on the linked website.  However, as various people have described, this type of change would be unlikely to even be considered.

As this kind of change is unlikely to even be considered in this form I won't write a formal proposal.

But I am not sure what part of the problem can be improved in some way.

I think the original C syntax for variable declaration is flawed. It is a trap for programmers. But changing such a core mechanism is cause extreme amount of code change.

I accept that a proposal for an extreme amount of code change cause extreme resistance.

Now we have two competing coding style to resolve this flaw but none of them is good enough. The two competing half solution cause headache. I think talking about this problem and proposing some changes at least worth this topic.

Peter