On 06/16/12 17:58, bearophile wrote: > Guillaume Chatelet: > >> A minimalistic website maintains the concepts defined so far and the >> C++ code >> http://www.elementsofprogramming.com/ > > That page looks quite interesting. I'll take a better look later (I have > not read that book).
The website is more of a stopgap, the book is way better because it shows the paths from concepts to concepts. I should warn the book is not easy to read, it's hard and it hurts, but it's good hurt. > In a recent (probably no more than one year old) talk by Bjarne > Stroustrup, he has shown a list of concepts that fits mostly in one > slide. So he has significantly reduced the number of Concepts needed for > the STL. Yes, you can hear him speak about it there http://channel9.msdn.com/Events/GoingNative/GoingNative-2012/A-Concept-Design-for-C- His proposal is also available ( also I'm not sure it's in sync with the video ) http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3351.pdf My main regrets regarding this proposal : * pervasive use of iterators instead of a more safe Range abstraction. * duplication of code with the xxxx_if variants ( all functions could take a default predicate evaluating to constexp true ). >> Now on the downside, D being a C-style-system-language, we won't be >> able to prevent implicit lossy conversions > > D disallows some implicit conversions (float => int, int => short, etc). > The conversions like uint=>int and int=>uint are an open problem, > waiting for some solution (a simple "solution" is to add a warning, as > in GCC. It's not a great solution, but maybe it's better than the > current D situation). Yes it's been debated several times on the ML and I agree a compiler warning could do. Every serious developer should toggle warning-as-errors anyway. >> or add value domain constrains as >> in the X10 language for instance. > > Please explain, don't assume all people here know X10. Sorry about that, you're absolutely right. X10 ( http://x10-lang.org/ ) allows user to add constrains on value domain definition at declaration time. Here are a few lines took from the documentation : * Int{self != 0} is the type of non-zero Ints. * Int{self != 0, self != 1} is the type of Ints which are neither zero nor one. * String{self != null} is the type of non-null strings. * Matrix{self.rows == self.cols} is the type of square matrices. -- Guillaume
