Oh, I thought you were trying to close the thread when you finished with "Thanks for sharing your thoughts."
PS: This thread stopped but still continues in lib.boost.devel. Here's a copy of my last post hoping it makes the purpose of v2 more clear.
I've been following it closely.
That's nice to know, thanks.
I came to the point where the motivation for using the library appeared to boil down to "initializer lists in C++ are broken, therefore we need a library solution." I don't know if they are broken, or how broken they are, or if they will or can be fixed. I do know that the fact that compilers don't *currently* support them is no good reason for a library. Boost.Assign should be obsolete with C++0x initializer lists. If that isn't the case then I would argue that initializer lists are broken in the standard. I use initializer lists every day in another langauge and they are really great. If we had to compromise between old and busted in C++98 and new hottness that we could get writing a language from scratch and got initializer list langauge features that fall somewhere between then t hat will be a bitter dissapointment for me. I was hoping someone could clarify just how broken or not-broken initializer lists are in the standard. Apparently containers have to explicitly declare an initializer list constructor. That's bad, but as long as every std container does so I can live with it. What about PODs? What about structs? What about default values of constructor arguments? What about explicit constructors? How are auto casting handled? Does initializer list have to be an exact match for the argument type? Does that result in function call ambiguity when trying to pass initializer lists? There are a lot of issues that I don't have time to dig into.
I have a feeling all these open questions are about C++0x, not V2, right?
I was trying to be merciful by not jumping onto the pile...
Generational gap, I suppose.
Regards, Luke