Oui, j'ai regardé, mais je ne vois pas de révolution par rapport à l'utilisation de boost::lambda, boost::function, ou encore d'un foncteur locale à une fonction.

Et bien le C++ dispose déjà de l'instanciation explicite de template, que tu peux compiler et poser dans un .o. Après, pour avoir l'instanciation implicite - comme c'est le plus élégant - il faut rendre le code template visible pour pouvoir générer du code.  

Ben vu qu'il n'y pas d'instanciation implicite de template, et que le C++ dispose déjà de l'instanciation explicite, je vois pas en quoi D est supérieur. Si, éventuellement la possiblité de paramétrer n'importe quelle scope ... mais bon, c'est un avantage mineur par rapport à la restriction précédente.
Pour l'avenir, les templates C++ vont acquérir une puissance assez extra-ordinaire, notament grâce à l'inférence de type et la notion de "concept" pour définir le contrat que doit respecter un paramètre générique, et permettre au compilo de donner un message d'erreur clair.

Dans la pratique, à quoi sert ceci : template Foo( T : A ) {} ?
Est-ce à forcer T à implémenter l'interface de A ? Si oui, c'est cette problématique que les "concepts" vont résoudre plus élégament.

Autre chose, est-ce que l'averload de fonction template fonctionne de la meme maniere qu'en C++ ?

enlève les __ en préfix, et c'est tout de suite moins imbitable

un avantage à avoir les tableaux dans la partie SL, c'est la possibilité de paramétrer statiquement une classe, un algorithme, ... avec au choix un des conteneurs standards std::vector, std::deque, ou std::list.

contraintes de performances, chère au C++ :|

Les policy classes et les mixins, c'est plus ou moins la même chose de mon point de vue.

Je ne vois pas ce que tu veux dire. Tu instancies ton template, oui, c'est normal. Mais pour rendre le code template visible, je ne vois pas comment faire autrement que de le mettre dans un .h, ce qui est très moche.

Je n'ai tjrs pas compris ce que tu appelles instanciation implicite de template. Mais le contrat c'est ce que font déjà les templates de D, si je comprends bien ce que c'est.

De même template Foo( T : U[] , U*, V = char) {...} est un template qui doit prendre en params un pointeur de type U et un tableau du même type, et un autre paramètre qui est un char par défaut (donc omettable, donc implicite, si tu veux). On peut définir ainsi la signature du template (est-ce le contrat dont tu parles ?).

Et honnêtemnet, avec tout ce qu'ajoute la nouvelle norme, je crains qu'avant que les compilos n'implémentent correctement, il ne se passe à nouveau 10 ans alors que D fait la majorité de ces innovations dès aujourd'hui. La raison en est que C++ doit gérer la compatibilité avec l'existant, pas D.

Honnêtement, j'ai pas regardé. Mais le scope d'un template D étant nettement plus large (on peut quasiment mettre un programme entier dans un template, et décider de le compiler avec des float ou des double, par exemple), j'imagine que ça n'est pas très différent d'un overload de fonction tout court.

 
Why do they want so many years to decide on so simple things that are other languages take for granted for more than 15 years now? Let's see what they have in store:
 
   1. the using declaration for making type aliases. First of all, template typedefs are there for the exact same reason. Secondly, C++ lacks the ability of making strong types out of other ones, templates or not; a feature present in Ada 83, for example. We programmers need the ability to define strong types out of anything, primitive, template or not.
   2. sequence constructors; what an utterly hopeless idea! it will introduce more problems than anyone ever thought. The correct thing would be to make the expression {2.3, 1.2, 6.7, 4.5}, and any expression contained in curly brackets, a composite literal! Just like an integer can be written as {0, 1, 0, 1 ... 1, 0, 0, 0, 1}, i.e. a sequence of bits, so should any other data structure. Array syntax would be more than enough for accessing the individual elements of a composite literal. For example: auto x = {1, 2, 3}; auto sum = x[0] + x[1] + x[2];
   3. template concepts; correct solution, but why they say it is difficult to implement? The problem with templates was that the type system was applied after template substitution. In fact, templates were little more than C macros. Languages that implement generics correctly (Haskell, Ml, Erlang, Ada, etc) have sold these problems many moons ago. Applying a type in compile time is nothing more than executing the program at compile time. Currently C++ templates are turing complete, so I just do not see 'big problems' with concepts.
   4. type deduction using the auto keyword. C++ already does type deduction, so where is the problem? And why should we wait 4 years for compilers to adopt those things?
   5. .
 
But what makes the most negative impression is the willingness to recognize that the programming language world has made huge steps in the last few years, and C++ is light years behind. Here are some of the negative points, in random order:
 
    * No garbage collection. Come on C++ guys! how many times have we got to beg for C++ having garbage collection? it's the easiest thing to do, and you can put it there as an option! no, the Boehm gc does not cut it, because it does not take advantage of type information, so it is much slower and much more complicated than what it needs to be. C++ designers, please stop telling us how garbage collection will mess up C++, because it will not! Microsoft already has managed C++, and then there is the programming language D which offers garbage collection! Of course gc goes hand-in-hand with strong and weak pointers.
    * the bias towards systems programming . Come on guys! in the world that Java is used for handheld devices, no one really cares about C++ being used in a few embedded controllers anyway. No one has used C++ for any major operating system, and no one has used C++ for any hardcore military project. Where is C++ used as for system programming? nowhere. C++ is mainly used in application programming, because of compatibility with C without an FFI.
    * the lack of import declarations. In the year 2006, we still have to duplicate code between header and source files, we still have to take care of includes, we still have to make decisions if we should place code in header files or in implementation files in order to make code inlined or not.
    * no static virtual methods. It is dead easy to do, and sometimes it is badly needed. For example, the pattern factory heavily depends on it.
    * no properties. For example, GUI libraries have 100s of widgets, yet we still have to write getFoo(), setFoo(), isFoo() etc. By using properties, code would be greatly simplified, and there would be no run-time overhead since properties is about syntactic sugar.
    * no variable argument lists in templates. Since the C++ language does not offer a way to write templates for a user-defined number of arguments, most frameworks have their own solution, one incompatible with each other, and very hard to maintain, using a rich palette of macro tricks, resulting in very slow compilation. Qt has signals and slots and requires the MOC compiler; GTK uses C signals and slots; and then we have stdsig++, boost signals, and lots of other frameworks. The D language has solved this with delegates.
    * No retrospection. If I wanted to make a GUI designer, for example, I would have to manually provide all the class and method information, or use macros and my own compiler (as Qt does)...but all I would be doing is duplicating the work that the compiler already does. Why can't I just query a class about its run-time structure, the methods it has, etc? there is no run-time overhead, and the provision of such information could be optional.
    * no standard GUI library. It requires lots of work, but basic GUI functionality should be there. Nothing spectacular, just the basic stuff (windows, menus, buttons, toolbars, etc) so we can easily write the most basic GUI applications. Stroustrup has said that "the C++ commitee will never agree on architecture". Well, they should put aside their egos and petit own interests and decide.
    * no way to get the size of an array allocated with operator new [] . Although the C++ standard dictates that the number of elements of an array is stored in the heap block (in order to use operator delete [], i.e. to know how many objects does the array contain), programmers are not allowed access to this information, for no particular reason. Besides being plain stupid, it requires wrapping up array functionality in templates (the std library does not contain such a template), and the number of elements exists in two places in memory.
    * No continuations. There is quite a big list of recursive algorithms that depend on not blowing the stack, and using continuations is the only way to achieve them. Yet, C++ denies such a facility, for no apparent reason.
    * No closures. It is quite frustrating to having to write a function far away from the place it is actually going to be used. It also stops GUI libraries from being simple. For example, I can not just define a button that closes a locally declared window. I have to declare the call that closes the window as a separate function, which means the window should be referenced globally.
    * No parameters-by-name function calls. Modern C++ components may have lots of parameters to be set in a constructor. For example, for a component that has 10 parameters, one has to declare 11 constructors. Using parameters-by-name, the programmer would not have to declare all those constructors. For example, a button with an optional bitmap would be constructed in one line of code, like this: new Button(parent = mainWindow, text = "hello world", bitmap = bitmap1, click = {mainWindow.close()});. Boost is going to have a library like that, but it is actually a non-thread-safe hack using macros.
    * No initialization of an object's fields at the point of their declaration. If a class has 10 fields, the same code that initializes those fields must either be repeated in every constructor, or the user should declare an initialize function that sets the fields to their default values. If, later, someone adds or removes some fields, then all the points of initialization should be changed.
    * No run-time substitution of a vtable's method pointers. C++ claims to be a "system's programming language", but the feature requested by most system programmers is the ability to modify the vtable of a class at run-time. This is a very important feature, because it allows to make objects that their behaviour depends on run-time parameters. For example, choosing the appropriate driver for a game. C++ denies this solution, forcing programmers to declare all the possible combinations at compile-time. This make it impossible, for example, to write an OpenGL driver in C++, where choices depend on lots of run-time parameters (user choices, video card capabilities, game engine capabilities, etc), forcing programmers to write vtables themselves in C fashion. There would be no run-time overhead for C++, since vtables exist, but yet C++ does not allow it.
    * No true message passing. The true benefits of object-orientation comes from message passing (see discussions about OO, Smalltalk and Simula). C++ does not have true message passing, like Java: it forces the programmer to declare an interface. The lack of true message passing forces library writers to write message maps manually (Microsoft's MFC, Borland's OWL, WxWidgets), all incompatible between themselves, and with various problems. Optional message passing would be of tremendous benefit, especially in GUI frameworks, where the host operating system might send thousands of different messages to an application (I am talking about Windows mainly here). Message passing would also be of tremendous benefit in rapid application development, where the programmer would not have to declare thousands of interfaces, as in modern C++/Java libraries.
 
As one can see, C++ has a lot of ground not covered yet. Many will say "don't use C++ then". Well, that argument is not acceptable, because C++ is the only widely accepted and portable language with the correct set of basic features. C++ is the only language, for example, that allows me to have stack based objects, thus saving resources and simplyfing programming. C++ is the only widely accepted language that allows direct usage of C libraries.
 
C++ could have been the dominant language, if it was not for the stubborness of the C++ committee to accept that programming languages are developed based on what the world needs, and not on what a few good men know.

Je suis en train de me demander si je ne vais pas expérimenter D pour essayer les futures nouveautés du C++, je me tate ...

Après, le degré de finesse auquel on étend ce "friend" est clairement affaire de goût : d'un coté,a vec des "friend" explicites, on obtient une grande finesse dans les droits d'accès, de l'autre, avec la règle retenue, on considère que l'auteur du module sait ce qu'il fait et on lui donne plus de liberté.