Re: [Boost-users] [review][assign] Formal review of Assign v2 ongoing

Subject: Re: [Boost-users] [review][assign] Formal review of Assign v2 ongoing
From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2011-06-23 17:29:04

er wrote:
> On 6/21/11 7:08 PM, er wrote:
>> 
>>> If it is true that you cannot use an initializer list with an
>>> explicit constructor in the new standard I think it will make
>>> explict constructors very painful. I may not have reasoned it
>>> through fully, 
>>> but I see no reason not to allow initializer lists to use explict
>>> constructors. It doesn't seem to create safety concerns or
>>> ambiguity. Does someone know the rationale for that? It seems to be
>>> a mistake to me. 
>> 
>> I'm only reporting what I observe, and I'm unable to make a judgment.
>> Hopefully someone with a later version of gcc can confirm or infirm.
>> 
>> In any case, it still leaves containers that have not been augmented
>> with initializer list constructors, such as queue, for which Assign
>> is helpful under C++0x, for the task of initializing a container.
>> 
>> Thanks for sharing your thoughts.
>> 
>>> Regards,
>>> Luke
> Did you get a chance to think it through? It would be nice to clarify
> this issue before the review closes, tomorrow.

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.

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 that 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.

In the end, dissapointment in the new standard isn't a strong position from which to motivate me to use the library.  I probably wouldn't use assign V1, but at least I find code that does use it readable.  The V2 syntax is unintelligable without reading the documentation.  Conciseness at the expense of readability is a horrible trade off.  Even if I wouldn't use a library myself, I would approve of it if I would approve of other people using it.  To each his own.  But a library that I object to other people using becaues I never want to come into contact with their code is another story.  First impression and subsequent discussion leads me to conclude that I never want to come into contact with code written the V2 syntax.  I much prefer the V1 syntax (even if I wouldn't actually use it) and I don't see the benefit of V2 over V1 or even V2 over vanilla C++ standard practice, even leaving aside C++0x initializer lists.  

I was trying to be merciful by not jumping onto the pile...

Regards,
Luke