This one may sound silly, but here it is:

Source code is the human interface to the language, and source code is edited in text editors. Most programming editors indent based on braces. The only reason i don't use deeply-nested namespaces in C++ (a-la Java) is because this indention gets unwieldy after 2-3 namespaces. Because source code is OUR interface to the language, i will propose a small amount of syntactic sugar to make it easier to nest namespaces without confusing editors:

Current syntax and typical usage:

namespace one {
(1x indent) namespace two {
(2x indent) namespace three {}
(1x indent) }
}


Suggested as an acceptable shortcut:


namespace one::two::three {

}


Easy enough to add to C++ parsers, i would think.

The significance is that editors which indent only have one indention level to deal with, and also their syntax-highlighting code may not even have to change to deal with it.

i wish... i wish... i wish...

For an in-language way to get the string form of a class' name.

e.g., i'd love to see a well-defined-behaviour restriction placed on typeid::name(). Even if it didn't return "MyClassName", i'd like it to be forced to return some standardized representation of a type's NAME. To make this easier on compiler implementors, a type name should not include any type modifier info, like const, *, &, etc., as in a string context they are not normally significant (in my experience).

I have probably overlooked it but I didn't see anything about implicit forward declarations and doing away with header files completely. I do not pretend to have breadth and insight on this issue, but I have seen other (respectable) people refer to header files as purely compiler assisting concept that is now obsolete given the power of the average machine and level of sophistication compilers achieved. Recursive dependency and source code redundancy are the two major problems stemming from header files that are just on the top of my head now.
But maybe I'm missing the whole point of this new version of C++ - is it supposed to be source-level backwards compatible?

I agree with you there. Many people have contended that header files provide documentation, but that is a false premise. They often give you more than you want (showing privates, etc.). They can be deceptive, especially when filled with lots of #ifdefs. They are almost always very cluttered. Automatically generated documentation (al la JavaDoc and the like) covers this need much more effectively and aesthetically.

However, from an implementation point of view in C++, it seems like the compiler would have to somehow know how to read libraries. That's kind of what Java and C# compilers do -- they don't have a separate compiler and linker apparently.

Probably a minor thing, but I would like to have the "substr" method on strings check for and handle strings that are out of bounds.

For instance, if I were to say something like this:
string foo="Hello";
string bar="";
bar=foo.substr(bar,10,10);

It should not give a run-time exception. It should merely set bar to "". (Just like awk, php and perl do!)

I do say it from my side of enterprise programmer, and I'm not taking into account all problems related to HW architectures and platforms.

This is also a high level and demanding list, therefore it may go out of the boundaries of what it can stay within the actual timeframes and scoping.

1 A standardized documetation facility (e.g. doxygen)

2 A metadata language support (e.g. xdoclet,jdk1.5)

3 A draft Support for reversibility from the implementation
to a "set of" design paradigms (e.g. UML and eiffel)
This feature can be nicely integrated with graph support,
documentation, metadata, and even the graphical
facilities

4 Draft support for the design by contract method

5 A standardized support for testing availble from the
asserts in the contracts

6 Aspects (e.g. aspects cpp)

7 A draft specification for a web service container,
taking into account also authentication

Kindly,
Diego Bragato

It's not my most important, or anything like it, but I haven't actually seen anyone else ever ask for it. It is trivial however.

Overloads of std::conj in <complex> for float, double and long double which simply return their argument, e.g.

double std::conj(double x) {return x;}

Why? So you can write a single template covering real and complex cases which involve conjugation. An inner product is a typical example, x * conj(y), which is x * y when real.

You could argue the case for other complex-only functions in <complex> such as arg, but I've not needed those. conj I have.

Add some support for delegation.

Ideally, something like Borland's __closure, but with support for static functions, with better integration into the type system, and with the full set of operations.

------------------------
Bare minimum proposal
------------------------
Modify section 5.2.10/9 to state that when a member function pointer(MFP) a of class X is converted using reinterpret_cast<> to another MFP b of a class Y __of incomplete type__ but the same signature, and a pointer p to X is converted to a pointer q to Y using static_cast<>, then
invoking (q->*b)() is equivalent to (p->*a)().

This works on every C++ compiler ever made. It allows creation of optimally efficient delegates. Here's an example implementation:

http://www.codeproject.com/cpp/FastDelegate.asp

Unfortunately, this code is not legal (even though it works on all compilers, albeit with some nasty tricks for the non-standard MFPs used by Microsoft/Intel). But with that trivial change to the standard, it could be made legal retrospectively.

The proposal has no side effects on other areas of the language. All extant compilers are automatically compliant.
And it adds a significant new concept to the language.
(In one of Herb's recent blogs, he mentioned that he drools over C# delegates. These are better, because they work with templates).

I doubt you'll find anything with a better "bang for your buck".

Of course it would be nice to have full language integration, especially with better error messages, and a defined ABI for delegate structures -- but please consider this kind of zero-cost option if a full implementation doesn't make the list.

I have two requests:

[1] Allow underscores within (i.e., inside, not at the beginning) an integer literal to improve readability.
See this thread in comp.lang.c++.moderated:
Message-ID: <22868227.0411021649.97c19df@posting.google.com>

[2] Raw string literals where back-slashes are just another character.
E.g.,
r"This is a \n special string \t where there are no new lines or tabs"
This would immensely help if C++ should be used for REs.

thanks,
- Anand

What I am missing in both list is improved/strongly typed enumerations. There have been some excelent proposals on comp.std.c++!

Personaly, I would also like the ability to extend an enumeration.
Say for example that a base class contains an
enum Base::color { r, g, b }
then it is sometimes desirable to have
enum Derived::color { Base::color, c, m ,y }
in a derived class.

The ability to divide the public portion of a class's interface into named "subsets". Users of the subset would need an explicit statement indicating the usage. For example:

class A
{
public: ... // just plain public
public X: ... // stuff in the X subset
public Y: ... // stuff in the Y subset
public X: ... // more stuff in the X subset
};

void foo (A &a)
{
using class A::X;
...
}

class B
{
using class A::X;
...
};

**********

In one large class heirarchy I worked with, there were a great many virtual function overrides that really just provided the value of a constant for some algorithm implemented in the base class, for example:

class Quarter : public Coin
{
public:
virtual int value(void) const ( return(25); }
...
};

It would be clearer (and improve performance a bit) to be able to say:

class Quarter : public Coin
{
public:
virtual int Value = 25;
...
};

The value of "Value" could be stored directly in the vstruct. The declaration:

class Coin
{
public:
virtual int Value;
...
};

would make "Coin" abstract, since no value for "Value" is given.

**********

A "psuedo-template" name footprint. The class footprint<A> would have the same size and alignment requirements as class A, but footprint<A> would have an vacuous implicit constructer and no other members. The purpose is this:

union X
{
footprint<A> a;
struct B b;
footprint <C> c;
};

X x;
...

// Use x to store an A instance, constructed using
// new placement syntax.
new (&x.a) A;

**********

In the same way that physicist are in need of a Unified Field Theory, I dream of a "Unified Meta-programming Mechanism" for C++. What I mean by this is some "thing" that would do everything that both templates and macros do and do it as well. For example, the "typeof" operator gives macros a fighting chance to act somewhat like function templates. Could a pre-processor with m4-type power and some set of "semantics-extraction" mechanisms (like typeof) take the place of templates? This is so brief and sketchy as to be useless. But maybe someone smarter than me can make something of it.

http://groups-beta.google.com/group/comp.lang.c++.moderated/browse_frm/thread/747d3f2b3a82524a

Here I propose idea of template typedef along with its syntax and some neat features it will allow. Please note that this is not 'usual' template typedef, i.e. you can not do like this:

template<class T>
typedef foo<T, U>* foo2<T>;

->

foo2<T> pVar;

equivalent to

foo<T, U>* pVar;

instead it is a direct mirroring of typedef to the templates world.


Also allowing forward declarations for type and template aliases will help! (or introduce implicit forwarding like in C#)

Bye.
Sincerely yours, Michael.

Also It would be REALLY great to enforce "nothrow" guarantee on all std library exceptions, i.e. std::logic_error, std::runtime_error and so on. Currently only std::exception and std::bad_exception has this guarantee.
Due to this it is impossible to write true reliable application which uses STL functionality capable to throw library-defined exceptions.

Bye.
Sincerely yours, Michael.

And once more:

time and date support is very sparse and ugly in C++ (mostly inherited from C).

I'd like to have :) :
1. convenient datetime representation and conversion methods, e.g. to convert given local Sydney time to Egypt local time

2. support for any linear time axis, i.e. datetime wich is always increasing and difference between datetime always == time that passed between them. Currently only Atomic time has these features (AFAIK) and there are not so much systems around supporting this time. UTC can be used with clear explanations of "leap seconds issues".
Also convenient conversion functions will be needed to convert this time to "usual human" time ("usual time" is our wall-clock time with all adjustments) and back with all ambiguities removed and clearly explained.

Once I was developing real-time system that was meant to bve running for VERY long time, and I had a lot of "fun" due to crippled datetime support in C++ and even in underlying system.

I believe C++ standard should enforce necessary rules upon platform to implement these features, or clearly describe how platform should emulate all or part of these rules.

Bye.
Sincerely yours, Michael.

virtual const data members

Today a vtable is really an initialized static const struct containing only pointers to functions (plus possibly some opaque data used by the run time system). I would very much like to be able to declare and initialize members of types other than simply pointer to function.

class C1 {
    // this single property costs a full pointer in the vtable
    virtual bool propertyX(void) const { return false; }
    ...
    // all together these properties occupy a single vtable byte
    virtual bool const propertyA : 1 = false;
    virtual bool const propertyB : 1 = false;
    virtual bool const propertyC : 1 = false;
    virtual bool const propertyD : 1 = false;
    virtual bool const propertyE : 1 = false;
    virtual bool const propertyF : 1 = false;
};
 
 
class C2 : C1 {
    // override a few properties
    virtual bool propertyX(void) const { return true; }
    ...
    virtual bool const propertyC : 1 = true;
};
 
 
void foo(C1& myC)
{
    // full cost of a virtual method dispatch
    if ( myC.propertyX() )
        ...;
 
    // single fetch, unaltered control flow, better register allocation
    if ( myC.propertyC )
        ...;
}