I've drafted a short proposal for a library to address issues with C++'s 'd=
eclarations mimic use' syntax and I'd like to know if there's enough intere=
st in this problem to merit further work and formal submission to the commi=
ttee.

https://github.com/socantre/LTR

# A Left To Right Declaration Syntax For C++

## Introduction

This proposal presents a library component that introduces simple left-to-r=
ight (LTR) declaration syntax to C++.

C's original 'declaration mimics use' (DMU) concept focuses on expressions =
and has an appealing simplicity and elegance. The concept was consistently =
applied and avoided redundant syntax for declaring and using entities. Howe=
ver, it proved not to be universally practical and alternatives for some ca=
ses were introduced and became best practices. For example, C89 offered a m=
ore type-explicit alternative syntax for function declarations:

    int f(x,y); // K&R style (DMU)
    int f(int,int); // Alternative, current practice

C++ places emphasis on types rather than on expressions [1] and introduces =
additional concepts that do not work well with C's DMU syntax. For example,=
 references have no associated 'use' syntax but must have distinct 'declara=
tion' syntax, and member-pointers for which a DMU syntax would face the sam=
e problems as the original K&R function declarations.

I propose a library component that uses C++11 template type aliases to intr=
oduce a simple LTR declaration syntax that is more in line with C++'s empha=
sis on types, is more consistent with the typical C++ user's conception of =
declarations and with declarations for other templated types, and solves so=
me issues currently dealt with using coding style conventions or mental tri=
cks.

## Motivation

- Many find the DMU syntax difficult to read or write and current practices=
 include methods and tricks to ease the burden. The methods typically aim t=
o keep individual declarations simple and as close to a LTR style as possib=
le. These include breaking complex compound types up using typedefs which c=
an then be used as simple type-specifiers, spacing rules that place type mo=
difiers to the 'left', and rules against declaring more than one variable p=
er declaration in avoid breaking the illusion created by such spacing rules=
..

 Tricks for reading complex compound declarations include the 'right to lef=
t' rule [2] for relatively simple declarations. For more complex declaratio=
ns there is the 'spiral rule'[3]. Additionally there are tools for decipher=
ing declarations, such as cdecl.org's "C gibberish =E2=86=94 English" trans=
lator which can convert between C's syntax and LTR English descriptions.

 Although Read/writability of the existing syntax can be a problem for any =
user it is a particular problem for novice users unfamiliar with the underl=
ying concept, and methods and tricks for dealing with it.=20

- Compound types have a natural order in which layers of more complex types=
 are built from simpler types. The 'spiral rule' amply demonstrates that th=
is order does not share a direct relation with the natural order in which C=
++ is read and written.

- DMU syntax is necessarily inconsistent with the syntax for templated type=
s. Templated types naturally use a consistent LTR syntax instead of the 'in=
side-out' or 'spiral' ordering of the built-in type modifiers.

- Language linkage is part of function types the syntax for declaring linka=
ges but is not consistent with other type modifying syntax. Typedefs are re=
quired to manipulate a function type's language linkage below the level of =
a whole declaration.

- Projects and individuals can use the solution I propose here, however inc=
luding a solution in the standard offers additional benefits such as easy, =
direct availability to novice users and potentially wider usage.

## Solution

    // header ltr_types
   =20
    namespace std {
    namespace ltr {
   =20
    template<typename T>                      using ptr       =3D T*;
    template<typename T>                      using ref       =3D T&;
    template<typename T>                      using rref      =3D T&&;
    template<typename T>                      using constant  =3D T const;
    template<typename T>                      using volat     =3D T volatil=
e;
    template<typename T, class C>             using mem_ptr   =3D T C::*;
    template<std::intmax_t N, typename T>     using raw_array =3D T[N];
    template<typename RetT, typename... Args> using func      =3D RetT(Args=
....);
    =20
    extern "C" template<typename T>   using c_linkage   =3D T;
    extern "C++" template<typename T> using cpp_linkage =3D T;
   =20
    } // namespace ltr
    } // namespace std
=20

With this library, declarations can be read and written in an intuitive LTR=
 fashion.

- Manual typedefs are replaced by these reusable template type aliases.
- The LTR ordering means the conceptual order of compound types matches the=
 order for reading and writing C++, making reading and writing easier and e=
liminating the need for tricks like the spiral and right-to-left rules.
- Limiting declarations to single variables is no longer necessary.
- The emphasis on types over expressions is more 'C++ like.'
- The template type alias syntax is consistent with the syntax for using ot=
her templated types.
- Language linkage type modifiers are consistent with other type modifiers =
and templates.

Additionally this library mixes well with the built-in syntax when desired.=
 E.g:

    ptr<int> foo(); // vs. func<ptr<int>> foo;

Complex compound type example:

    // A declaration randomly generated by cdecl.org=20
    // char * const (*(* const bar)[5])(int );=20

    constant<ptr<raw_array<5,ptr<func<constant<ptr<char>>,int>>>>> bar;

The LTR type resembles cdecl.org's 'English' explanation:

> declare bar as const pointer to array 5 of pointer to function (int) retu=
rning const pointer to char

## Disadvantages

- Using these template type aliases is not as compact as the built-in synta=
x.

- DMU syntax allows a single declaration to declare variables of different,=
 though related, types.

- The LTR syntax is not universally usable. For example it cannot be used f=
or a function definition or on a class definition:

        func<int,int> times_two=20
        {
            return arg1*2;
        }

        ptr<struct S {}> sPtr;

- The use of template type aliases doesn't mix with auto:

        rref<auto> x =3D foo(); // auto &&x =3D foo();

        int bar(rref<auto> x); // int bar(auto &&x);

[1]: http://www.stroustrup.com/bs_faq2.html#whitespace
[2]: http://ieng9.ucsd.edu/~cs30x/rt_lt.rule.html
[3]: http://c-faq.com/decl/spiral.anderson.html

--=20

---=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.



.

On 2/26/13, seth.cantrell@gmail.com <seth.cantrell@gmail.com> wrote:
> I've drafted a short proposal for a library to address issues
> with C++'s 'declarations mimic use' syntax and I'd like to know
> if there's enough interest in this problem to merit further work
> and formal submission to the committee.
>
> https://github.com/socantre/LTR

This proposal seems like something that can be a Boost component.
I don't know how popular such a component would be, but if there
is demand it will show up in the Boost users.

--
Lawrence Crowl

--

---
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-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

------=_Part_239_7688869.1361963450096
Content-Type: text/plain; charset=ISO-8859-1

I disagree Lawrence, we already have most of these components in the
Standard in the form of add_pointer and friends, he has just proposed a
shorter syntax for using them, which is not necessarily good or bad, but
it's certainly not a new library or new functionality.

--

---
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-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_239_7688869.1361963450096
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I disagree Lawrence, we already have most of these components in the Standa=
rd in the form of add_pointer and friends, he has just proposed a shorter s=
yntax for using them, which is not necessarily good or bad, but it's certai=
nly not a new library or new functionality.

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_239_7688869.1361963450096--

.

On 2/27/13, DeadMG <wolfeinstein@gmail.com> wrote:
> I disagree Lawrence, we already have most of these components in the
> Standard in the form of add_pointer and friends, he has just proposed a
> shorter syntax for using them, which is not necessarily good or bad, but
> it's certainly not a new library or new functionality.

What do you disagree with?  That they could be Boost components?
That popularity in Boost would mean something?

I never claimed that the proposal was new functionality.  My concern
is whether or not it has enough value to add to the standard.  I don't
know whether or not it does, but the Boost route is one way to show
value.

--
Lawrence Crowl

--

---
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-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

------=_Part_371_25235050.1362071826519
Content-Type: text/plain; charset=ISO-8859-1

I disagree that the Boost and whatnot has any relevance. For one, the vast
majority of Boost components do not appear to have had any substantial
C++11 work done to them. For two, given there's existing practice *in the
Standard itself*, the existing Boost practice seems quite irrelevant.

The proposal is just a quick simplification of existing Standard practice.

--

---
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-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_371_25235050.1362071826519
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I disagree that the Boost and whatnot has any relevance. For one, the vast =
majority of Boost components do not appear to have had any substantial C++1=
1 work done to them. For two, given there's existing practice *in the Stand=
ard itself*, the existing Boost practice seems quite irrelevant.<div><br></=
div><div>The proposal is just a quick simplification of existing Standard p=
ractice.</div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_371_25235050.1362071826519--

.

------=_Part_1614_31483152.1362109705645
Content-Type: text/plain; charset=ISO-8859-1

"My concern is whether or not it has enough value to add to the standard"

The value of this proposal is in replacing the language's declaration
syntax. It's a valid question whether the built-in syntax is problematic
enough to deserve being replaced*, or whether this component does it the
right way, but the value of any 'replacement' is substantially reduced,
especially for novices, by being external to the standard.

* Bjarne Stroustrup once said the syntax made him feel 'really dumb' when
he learned how to declare a function pointer without typedefs, and also
says in *The Design and Evolution of C++* that he's unhappy with the
syntax. Herb Sutter has talked about replacing the syntax (e.g.,
http://channel9.msdn.com/Shows/Going+Deep/Herb-Sutter-C-Questions-and-Answers)
though now he seems to prefer simply using auto. I still see complaints
about the 'inside-out' syntax pretty regularly, both from novices (See
http://stackoverflow.com/questions/7967594/why-is-the-c-variable-declaration-syntax-inconsistent/7968057#7968057
for just one of a myriad of examples) and from experience users that just
don't like it (See the last post on this forum page:
http://arstechnica.com/civis/viewtopic.php?f=20&t=1159182&start=2600).

--

---
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-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_1614_31483152.1362109705645
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div>"My concern&nbsp;is whether or not it has enough value to add to the s=
tandard"</div><div><br></div><div>The value of this proposal is in replacin=
g the language's declaration syntax. It's a valid question whether the buil=
t-in syntax is problematic enough to deserve being replaced*, or whether th=
is component does it the right way, but the value of any 'replacement' is s=
ubstantially reduced, especially for novices, by being external to the stan=
dard.</div><div><br></div><div>* Bjarne Stroustrup once said the syntax mad=
e him feel 'really dumb' when he learned how to declare a function pointer =
without typedefs, and also says in <i>The Design and Evolution of C++</i>&n=
bsp;that he's unhappy with the syntax. Herb Sutter has talked about replaci=
ng the syntax (e.g., http://channel9.msdn.com/Shows/Going+Deep/Herb-Sutter-=
C-Questions-and-Answers) though now he seems to prefer simply using auto. I=
 still see complaints about the 'inside-out' syntax pretty regularly, both =
from novices (See http://stackoverflow.com/questions/7967594/why-is-the-c-v=
ariable-declaration-syntax-inconsistent/7968057#7968057 for just one of a m=
yriad of examples) and from experience users that just don't like it (See t=
he last post on this forum page: http://arstechnica.com/civis/viewtopic.php=
?f=3D20&amp;t=3D1159182&amp;start=3D2600).</div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1614_31483152.1362109705645--

.

I personally would love to have it.
Just my 2 euro cents.

On 3/1/13, seth.cantrell@gmail.com <seth.cantrell@gmail.com> wrote:
> "My concern is whether or not it has enough value to add to the standard"
>
> The value of this proposal is in replacing the language's declaration
> syntax. It's a valid question whether the built-in syntax is problematic
> enough to deserve being replaced*, or whether this component does it the
> right way, but the value of any 'replacement' is substantially reduced,
> especially for novices, by being external to the standard.
>
> * Bjarne Stroustrup once said the syntax made him feel 'really dumb' when
> he learned how to declare a function pointer without typedefs, and also
> says in *The Design and Evolution of C++* that he's unhappy with the
> syntax. Herb Sutter has talked about replacing the syntax (e.g.,
> http://channel9.msdn.com/Shows/Going+Deep/Herb-Sutter-C-Questions-and-Answers)
>
> though now he seems to prefer simply using auto. I still see complaints
> about the 'inside-out' syntax pretty regularly, both from novices (See
> http://stackoverflow.com/questions/7967594/why-is-the-c-variable-declaration-syntax-inconsistent/7968057#7968057
>
> for just one of a myriad of examples) and from experience users that just
> don't like it (See the last post on this forum page:
> http://arstechnica.com/civis/viewtopic.php?f=20&t=1159182&start=2600).
>
> --
>
> ---
> 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-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
>
>
>

--

---
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-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

------=_Part_2146_7844914.1362139352844
Content-Type: text/plain; charset=ISO-8859-1

I think this has two issues.
- It's too much to type to actually be used
- We have identified a problem in the language, and you're proposing a
workaround in the library. That's not really a solution to the core problem.

Why can't we just allow such declarations:
int[5]* p; // pointer to array of 5 ints
void()* q; // pointer to nullary function returning void
int foo::* r; // pointer to int member of `foo'
bool() const foo::*&& s; // rvalue reference to pointer to const nullary
member function of `foo' returning bool
Would that introduce any ambiguities?

--

---
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-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_2146_7844914.1362139352844
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I think this has two issues.<br>- It's too much to type to actually be used=
<br>- We have identified a problem in the language, and you're proposing a =
workaround in the library. That's not really a solution to the core problem=
..<br><br>Why can't we just allow such declarations:<br><div class=3D"pretty=
print" style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187=
, 187, 187); border-style: solid; border-width: 1px; word-wrap: break-word;=
"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"=
color: #008;" class=3D"styled-by-prettify">int</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">[</span><span style=3D"color: #066;" cl=
ass=3D"styled-by-prettify">5</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">]*</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> p</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #800;" class=3D"styled-by-prettify">// pointer to ar=
ray of 5 ints</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">voi=
d</span><span style=3D"color: #660;" class=3D"styled-by-prettify">()*</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> q</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #80=
0;" class=3D"styled-by-prettify">// pointer to nullary function returning v=
oid</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></s=
pan><span style=3D"color: #008;" class=3D"styled-by-prettify">int</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> foo</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">::*</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> r</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=3D"styl=
ed-by-prettify">// pointer to int member of `foo'</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">bool</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">()</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">const</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> foo</span><span style=3D"color: #660;" class=3D"styled-by-prettify">:=
:*&amp;&amp;</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> s</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span s=
tyle=3D"color: #800;" class=3D"styled-by-prettify">// rvalue reference to p=
ointer to const nullary member function of `foo' returning bool</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div></cod=
e></div>Would that introduce any ambiguities?<br>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_2146_7844914.1362139352844--

.